GNU bug report logs -
#62450
29.0.60; Skip failing tests on Cygwin with native compilation
Previous Next
Reported by: Ken Brown <kbrown <at> cornell.edu>
Date: Sat, 25 Mar 2023 20:57:02 UTC
Severity: normal
Found in version 29.0.60
Done: Ken Brown <kbrown <at> cornell.edu>
Bug is archived. No further changes may be made.
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.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62450
; Package
emacs
.
(Sat, 25 Mar 2023 20:57:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ken Brown <kbrown <at> cornell.edu>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 25 Mar 2023 20:57:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62450
; Package
emacs
.
(Sun, 26 Mar 2023 04:46:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 62450 <at> debbugs.gnu.org (full text, mbox):
> 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.)
Reply sent
to
Ken Brown <kbrown <at> cornell.edu>
:
You have taken responsibility.
(Sun, 26 Mar 2023 14:16:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ken Brown <kbrown <at> cornell.edu>
:
bug acknowledged by developer.
(Sun, 26 Mar 2023 14:16:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 62450-done <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62450
; Package
emacs
.
(Sun, 26 Mar 2023 14:55:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 62450 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62450
; Package
emacs
.
(Sun, 26 Mar 2023 15:14:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 62450 <at> debbugs.gnu.org (full text, mbox):
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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 24 Apr 2023 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 359 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.