bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure

bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure

[Lars Ingebrigtsen]

This test started failing a few weeks ago:

Test bytecomp-tests--dest-mountpoint backtrace:
  signal(ert-test-failed (((status . 255) (output . "Cannot open load 
  ert-fail(((status . 255) (output . "Cannot open load file: No such f
  (if (eql status 0) nil (ert-fail (list (cons 'status status) (cons '
  (let ((status (call-process bwrap nil t nil "--ro-bind" "/" "/" "--b
  (progn (let ((status (call-process bwrap nil t nil "--ro-bind" "/" "
  (unwind-protect (progn (let ((status (call-process bwrap nil t nil "
  (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
  (let ((temp-buffer (generate-new-buffer " *temp*" t))) (save-current
  (let* ((input-file (expand-file-name "test.el" directory)) (output-f
  (unwind-protect (let* ((input-file (expand-file-name "test.el" direc
  (let ((directory (make-temp-file "bytecomp-tests-" :directory))) (un
  (let ((bwrap (executable-find "bwrap")) (emacs (expand-file-name inv
  (closure (t) nil (let ((bwrap (executable-find "bwrap")) (emacs (exp
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name bytecomp-tests--dest-mountpoint :docu
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (tag :unstable)) #f(compiled-function (event-type
  ert-run-tests-batch((not (tag :unstable)))
  ert-run-tests-batch-and-exit((not (tag :unstable)))
  command-line-1(("-L" ":." "-L" "./../../elpa/packages/url-http-ntlm/
  command-line()
  normal-top-level()
Test bytecomp-tests--dest-mountpoint condition:
    (ert-test-failed
     ((status . 255)
      (output . "Cannot open load file: No such file or directory, debug\12")))
   FAILED   8/75  bytecomp-tests--dest-mountpoint (0.036923 sec)

This apparently only happens if you have bwrap (part of the bubblewrap
package) installed -- otherwise the test is skipped.



In GNU Emacs 28.0.50 (build 71, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-05-10 built on xo
Repository revision: aa354dd55b213b86ee8e3aa0365a6ad915838458
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Debian GNU/Linux bullseye/sid

Configured using:
 'configure --with-native-compilation'


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure

[Philipp Stephani]

Am Di., 11. Mai 2021 um 16:07 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>
>
> This test started failing a few weeks ago:
>
> Test bytecomp-tests--dest-mountpoint backtrace:
>   signal(ert-test-failed (((status . 255) (output . "Cannot open load
>   ert-fail(((status . 255) (output . "Cannot open load file: No such f
>   (if (eql status 0) nil (ert-fail (list (cons 'status status) (cons '
>   (let ((status (call-process bwrap nil t nil "--ro-bind" "/" "/" "--b
>   (progn (let ((status (call-process bwrap nil t nil "--ro-bind" "/" "
>   (unwind-protect (progn (let ((status (call-process bwrap nil t nil "
>   (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
>   (let ((temp-buffer (generate-new-buffer " *temp*" t))) (save-current
>   (let* ((input-file (expand-file-name "test.el" directory)) (output-f
>   (unwind-protect (let* ((input-file (expand-file-name "test.el" direc
>   (let ((directory (make-temp-file "bytecomp-tests-" :directory))) (un
>   (let ((bwrap (executable-find "bwrap")) (emacs (expand-file-name inv
>   (closure (t) nil (let ((bwrap (executable-find "bwrap")) (emacs (exp
>   ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
>   ert-run-test(#s(ert-test :name bytecomp-tests--dest-mountpoint :docu
>   ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
>   ert-run-tests((not (tag :unstable)) #f(compiled-function (event-type
>   ert-run-tests-batch((not (tag :unstable)))
>   ert-run-tests-batch-and-exit((not (tag :unstable)))
>   command-line-1(("-L" ":." "-L" "./../../elpa/packages/url-http-ntlm/
>   command-line()
>   normal-top-level()
> Test bytecomp-tests--dest-mountpoint condition:
>     (ert-test-failed
>      ((status . 255)
>       (output . "Cannot open load file: No such file or directory, debug\12")))
>    FAILED   8/75  bytecomp-tests--dest-mountpoint (0.036923 sec)
>
> This apparently only happens if you have bwrap (part of the bubblewrap
> package) installed -- otherwise the test is skipped.
>

That doesn't happen for me, even with bwrap installed. The error
message seems to imply that the sandboxed Emacs can't load its builtin
libraries; maybe they are inaccessible or the load path is not set up
correctly? The stack trace entry
    command-line-1(("-L" ":." "-L" "./../../elpa/packages/url-http-ntlm/
makes it look like you're using a nonstandard load path that includes
some directories that are not part of Emacs, maybe that's the problem?

bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure

[Lars Ingebrigtsen]

Philipp Stephani <p.stephani2@gmail.com> writes:

> That doesn't happen for me, even with bwrap installed. The error
> message seems to imply that the sandboxed Emacs can't load its builtin
> libraries; maybe they are inaccessible or the load path is not set up
> correctly? The stack trace entry
>     command-line-1(("-L" ":." "-L" "./../../elpa/packages/url-http-ntlm/
> makes it look like you're using a nonstandard load path that includes
> some directories that are not part of Emacs, maybe that's the problem?

No, that's how the command line is set up by default if you have an elpa
directory on the same level as the Emacs directory.

With that moved out of the way, the trace is

  ert-run-tests-batch-and-exit((not (tag :unstable)))
  command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/emacs-lisp/bytecomp-
  command-line()
  normal-top-level()

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure

[Lars Ingebrigtsen]

Another data point -- it only seems to fail when native compilation is
switched on?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure

[Lars Ingebrigtsen]

It's pretty frustrating -- if I eval it like this:

(call-process "/usr/bin/bwrap" nil t nil  "--ro-bind" "/" "/" "--bind" "/tmp/bytecomp-tests-gJRuM4/test.elc" "/tmp/bytecomp-tests-gJRuM4/test.elc" "/home/larsi/src/emacs/trunk/src/emacs" "--quick" "--batch" "--load=bytecomp" "--eval=(setq byte-compile-dest-file-function (lambda (_) \"/tmp/bytecomp-tests-gJRuM4/test.elc\") byte-compile-error-on-warn t)" "--funcall=batch-byte-compile" "/tmp/bytecomp-tests-gJRuM4/test.el")

then it works.  And it works on the command line.  It only fails when
running the test.  If I eval the test itself in a running Emacs, it also
works.

Most puzzling.  And it's even more frustrating that it's impossible to
get anything sensible out of the failing instance -- it fails when
trying to load stuff to report the error, I think?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Most puzzling.  And it's even more frustrating that it's impossible to
> get anything sensible out of the failing instance -- it fails when
> trying to load stuff to report the error, I think?

Yes, indeed, and that's because --batch now outputs a backtrace, which
loads debug.el, and since we're in a chroot, Emacs can't load that file?

So I disabled that, and got the real error:

Test bytecomp-tests--dest-mountpoint condition:
    (ert-test-failed
     ((status . 255)
      (output . "Creating directory with prefix: Read-only file system, /home/larsi/src/emacs/trunk/test/emacs-testsuite-\n")))

And...  that's from here?

      ;; When $HOME is set to '/nonexistent' means we are running the
      ;; testsuite, add a temporary folder in front to produce there
      ;; new compilations.
      (when (equal (getenv "HOME") "/nonexistent")
        (let ((tmp-dir (make-temp-file "emacs-testsuite-" t)))
          (add-hook 'kill-emacs-hook (lambda () (delete-directory tmp-dir t)))
          (push tmp-dir native-comp-eln-load-path))))

Hm...  is there no way to disable all the nativecomp stuff?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  is there no way to disable all the nativecomp stuff?

I just made the startup.el stuff more robust instead.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure

[Philipp]

> Am 12.08.2021 um 01:06 schrieb Lars Ingebrigtsen <larsi@gnus.org>:
> 
>      ;; When $HOME is set to '/nonexistent' means we are running the
>      ;; testsuite, add a temporary folder in front to produce there
>      ;; new compilations.
>      (when (equal (getenv "HOME") "/nonexistent")
>        (let ((tmp-dir (make-temp-file "emacs-testsuite-" t)))
>          (add-hook 'kill-emacs-hook (lambda () (delete-directory tmp-dir t)))
>          (push tmp-dir native-comp-eln-load-path))))


Such code is quite brittle.  Code should generally not try to detect whether it's running as part of a test, and not make decisions based on sich a detection, because such logic thwarts the idea of testing the actual code that runs in production.  I'd recommend deleting this snippet and finding a better way to achieve its goal.

bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure

[Lars Ingebrigtsen]

Philipp <p.stephani2@gmail.com> writes:

> Such code is quite brittle.  Code should generally not try to detect
> whether it's running as part of a test, and not make decisions based
> on sich a detection, because such logic thwarts the idea of testing
> the actual code that runs in production.  I'd recommend deleting this
> snippet and finding a better way to achieve its goal.

I agree.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no