GNU bug report logs - #62450
29.0.60; Skip failing tests on Cygwin with native compilation

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 62450 in the body.
You can then email your comments to 62450 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: Ken Brown <kbrown <at> cornell.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; Skip failing tests on Cygwin with native compilation
Date: Sat, 25 Mar 2023 16:55:49 -0400

[Message part 1 (text/plain, inline)]

When 'make check' is run on Cygwin and Emacs has been built with native
compilation, all the tests in comp-tests.el and benchmark-tests.el fail
with fork errors, for the reasons explained in etc/PROBLEMS.  I don't
see an easy way to fix this by rebasing, as is done elsewhere in the
code, and I don't think it's worth investing any effort into this just
for the sake of making some tests pass.  I propose that we just skip
these tests.

Patch attached (with a placeholder for the bug number).  OK for emacs-29?

Ken

[0001-Skip-failing-tests-on-Cygwin-with-native-compilation.patch (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 62450 <at> debbugs.gnu.org
Subject: Re: bug#62450: 29.0.60;
 Skip failing tests on Cygwin with native compilation
Date: Sun, 26 Mar 2023 07:44:52 +0300

> Date: Sat, 25 Mar 2023 16:55:49 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> 
> When 'make check' is run on Cygwin and Emacs has been built with native
> compilation, all the tests in comp-tests.el and benchmark-tests.el fail
> with fork errors, for the reasons explained in etc/PROBLEMS.  I don't
> see an easy way to fix this by rebasing, as is done elsewhere in the
> code, and I don't think it's worth investing any effort into this just
> for the sake of making some tests pass.  I propose that we just skip
> these tests.
> 
> Patch attached (with a placeholder for the bug number).  OK for emacs-29?

OK, but please add in both places comments explaining the reason, and
in particular include there a pointer to etc/PROBLEMS.

(I do wonder whether this is a good idea in the long run.  Native
compilation is here to stay, so avoiding its testing for Cygwin might
not be the best solution.  The PROBLEMS entry seems to imply that
relatively simple measures, which the test suite could take, could
avoid the fork failures, so my recommendation would be to try to find
a better fix in the future, albeit not in Emacs 29.)

Message #13 received at 62450-done <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62450-done <at> debbugs.gnu.org
Subject: Re: bug#62450: 29.0.60; Skip failing tests on Cygwin with native
 compilation
Date: Sun, 26 Mar 2023 10:15:17 -0400

On 3/26/2023 12:44 AM, Eli Zaretskii wrote:
> OK, but please add in both places comments explaining the reason, and
> in particular include there a pointer to etc/PROBLEMS.

Done.

> (I do wonder whether this is a good idea in the long run.  Native
> compilation is here to stay, so avoiding its testing for Cygwin might
> not be the best solution.  The PROBLEMS entry seems to imply that
> relatively simple measures, which the test suite could take, could
> avoid the fork failures, so my recommendation would be to try to find
> a better fix in the future, albeit not in Emacs 29.)

I agree, and I hope I can do it.  By the way, I've been experimenting 
with building the .eln files with ASLR enabled, via the following:

--- a/lisp/emacs-lisp/comp.el
+++ b/lisp/emacs-lisp/comp.el
@@ -186,8 +186,9 @@ native-comp-compiler-options
   :type '(repeat string)
   :version "28.1")

-(defcustom native-comp-driver-options (when (eq system-type 'darwin)
-                                        '("-Wl,-w"))
+(defcustom native-comp-driver-options
+  (cond ((eq system-type 'darwin) '("-Wl,-w"))
+        ((eq system-type 'cygwin) '("-Wl,-dynamicbase")))
   "Options passed verbatim to the native compiler's back-end driver.
 Note that not all options are meaningful; typically only the options
 affecting the assembler and linker are likely to be useful.

I've been building and running Emacs like this for a couple months and 
not doing any rebasing, and I haven't seen a single fork failure outside 
of the test suite.  So this might be the way to handle the problem in 
the long run.  But I still hope to figure out what's different about 
native compilation in the test suite.

Ken

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 62450 <at> debbugs.gnu.org
Subject: Re: bug#62450: 29.0.60; Skip failing tests on Cygwin with native
 compilation
Date: Sun, 26 Mar 2023 17:54:26 +0300

> Date: Sun, 26 Mar 2023 10:15:17 -0400
> Cc: 62450-done <at> debbugs.gnu.org
> From: Ken Brown <kbrown <at> cornell.edu>
> 
> On 3/26/2023 12:44 AM, Eli Zaretskii wrote:
> 
> > (I do wonder whether this is a good idea in the long run.  Native
> > compilation is here to stay, so avoiding its testing for Cygwin might
> > not be the best solution.  The PROBLEMS entry seems to imply that
> > relatively simple measures, which the test suite could take, could
> > avoid the fork failures, so my recommendation would be to try to find
> > a better fix in the future, albeit not in Emacs 29.)
> 
> I agree, and I hope I can do it.

Great, thanks.

> By the way, I've been experimenting with building the .eln files
> with ASLR enabled, via the following:
> 
> --- a/lisp/emacs-lisp/comp.el
> +++ b/lisp/emacs-lisp/comp.el
> @@ -186,8 +186,9 @@ native-comp-compiler-options
>     :type '(repeat string)
>     :version "28.1")
> 
> -(defcustom native-comp-driver-options (when (eq system-type 'darwin)
> -                                        '("-Wl,-w"))
> +(defcustom native-comp-driver-options
> +  (cond ((eq system-type 'darwin) '("-Wl,-w"))
> +        ((eq system-type 'cygwin) '("-Wl,-dynamicbase")))
>     "Options passed verbatim to the native compiler's back-end driver.
>   Note that not all options are meaningful; typically only the options
>   affecting the assembler and linker are likely to be useful.
> 
> I've been building and running Emacs like this for a couple months and 
> not doing any rebasing, and I haven't seen a single fork failure outside 
> of the test suite.  So this might be the way to handle the problem in 
> the long run.

Feel free to install the above on master.

> But I still hope to figure out what's different about native
> compilation in the test suite.

You mean, why the fork fails?  I thought the PROBLEMS entry explains
that?

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62450 <at> debbugs.gnu.org
Subject: Re: bug#62450: 29.0.60; Skip failing tests on Cygwin with native
 compilation
Date: Sun, 26 Mar 2023 11:13:36 -0400

On 3/26/2023 10:54 AM, Eli Zaretskii wrote:
>> Date: Sun, 26 Mar 2023 10:15:17 -0400
>> Cc: 62450-done <at> debbugs.gnu.org
>> From: Ken Brown <kbrown <at> cornell.edu>

>> I've been building and running Emacs like this for a couple months and
>> not doing any rebasing, and I haven't seen a single fork failure outside
>> of the test suite.  So this might be the way to handle the problem in
>> the long run.
> 
> Feel free to install the above on master.

Good idea.  That way maybe it will get some more testing.  AFAIK, I'm 
the only one who's tried this so far (at the suggestion of Corinna, the 
Cygwin maintainer).

>> But I still hope to figure out what's different about native
>> compilation in the test suite.
> 
> You mean, why the fork fails?  I thought the PROBLEMS entry explains
> that?

No, I mean why ASLR doesn't prevent the fork failure in the test suite, 
even though it prevents it while building Emacs and in my daily use of 
Emacs.  Or maybe a better question is whether my ASLR patch is actually 
taking effect for the compilations done in the test suite.  There has to 
be something different going on there, but I don't know what.

Ken

Previous Next

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