GNU bug report logs - #48350
28.0.50; bytecomp-tests--dest-mountpoint test failure

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48350 in the body.
You can then email your comments to 48350 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; bytecomp-tests--dest-mountpoint test failure
Date: Tue, 11 May 2021 16:05:29 +0200

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

Message #8 received at 48350 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 48350 <at> debbugs.gnu.org
Subject: Re: bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure
Date: Tue, 11 May 2021 16:42:48 +0200

Am Di., 11. Mai 2021 um 16:07 Uhr schrieb Lars Ingebrigtsen <larsi <at> 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?

Message #11 received at 48350 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 48350 <at> debbugs.gnu.org
Subject: Re: bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure
Date: Tue, 11 May 2021 16:46:15 +0200

Philipp Stephani <p.stephani2 <at> 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

Message #14 received at 48350 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 48350 <at> debbugs.gnu.org
Subject: Re: bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure
Date: Wed, 12 May 2021 22:08:26 +0200

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

Message #17 received at 48350 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 48350 <at> debbugs.gnu.org
Subject: Re: bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure
Date: Thu, 12 Aug 2021 00:34:40 +0200

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

Message #20 received at 48350 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 48350 <at> debbugs.gnu.org
Subject: Re: bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure
Date: Thu, 12 Aug 2021 01:06:42 +0200

Lars Ingebrigtsen <larsi <at> 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

Message #23 received at 48350 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 48350 <at> debbugs.gnu.org
Subject: Re: bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure
Date: Thu, 12 Aug 2021 01:20:04 +0200

Lars Ingebrigtsen <larsi <at> 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

Message #28 received at 48350 <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 48350 <at> debbugs.gnu.org
Subject: Re: bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure
Date: Sat, 4 Sep 2021 21:30:50 +0200

> Am 12.08.2021 um 01:06 schrieb Lars Ingebrigtsen <larsi <at> 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.

Message #31 received at 48350 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 48350 <at> debbugs.gnu.org
Subject: Re: bug#48350: 28.0.50; bytecomp-tests--dest-mountpoint test failure
Date: Sun, 05 Sep 2021 11:37:17 +0200

Philipp <p.stephani2 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.