GNU bug report logs - #29040
emacs-26 crash due to misaligned longjmp buffer in 64-bit MSYS2/MinGW-W64 build

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 29040 in the body.
You can then email your comments to 29040 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: Richard Copley <rcopley <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: emacs-26 crash due to misaligned longjmp buffer in 64-bit
 MSYS2/MinGW-W64 build
Date: Sat, 28 Oct 2017 14:40:41 +0100

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

When I build from the current emacs-26 branch with the current 64-bit
mingw-w64 toolchain from MSYS2, with optimization, Emacs sometimes
crashes with a segfault on typing C-g.

As far as I can tell, the current 64-bit pretest is not affected.

The attached file "servicelistpage.txt" helps to reproduce the crash.
It was created by the OP in this thread on help-gnu-emacs:

<http://lists.gnu.org/archive/html/help-gnu-emacs/2017-10/msg00089.html>

To reproduce the build with the 64-bit MinGW-W64 toolchain from MSYS2,

 * Save a backup of your MSYS2 installation, if it is in working order.
 * Update MSYS2.
 * In MSYS2 MINGW64 shell in the emacs repo:

git reset --hard 68182a47
git clean -xfd
./autogen.sh
./configure --with-modules --without-pop 'CFLAGS=-O1 -ggdb3'
make -j8 -O

Then, to reproduce the crash from "src/emacs -Q servicelistpage.txt":

 * Wait for the buffer to be displayed.
 * Type [C-g].

Partial GDB backtrace (full backtrace attached):

Thread 1 (Thread 5480.0x1e9c):
#0  0x00007ffaa1b693a0 in ntdll!RtlCaptureContext ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ffaa1ad8f27 in ntdll!RtlUnwindEx ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ffaa0671f4a in msvcrt!_setjmpex ()
   from C:\WINDOWS\System32\msvcrt.dll
No symbol table info available.
#3  0x00000004000b1a9a in quit_throw_to_read_char (
    from_signal=from_signal <at> entry=false) at keyboard.c:10548
No locals.

The faulting instruction in ntdll!RtlCaptureContext (frame #0) is

0x00007ffaa1b693a0 <+384>:   movaps 0x60(%rax),%xmm0

The memory operand should be 16-byte aligned but it is not. That is
the cause of the segfault. I think the following extract from the GDB
session shows the problem. The value in %rax is 0x4005CDAE8 (not
16-byte aligned).

(gdb) p $rax
$1 = 17185954536
(gdb) up
#1  0x00007ffaa1ad8f27 in ntdll!RtlUnwindEx ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) up
#2  0x00007ffaa0671f4a in msvcrt!_setjmpex ()
   from C:\WINDOWS\System32\msvcrt.dll
(gdb) up
#3  0x00000004000b1a9a in quit_throw_to_read_char (
    from_signal=from_signal <at> entry=false) at keyboard.c:10548
10548     sys_longjmp (getcjmp, 1);
(gdb) p &getcjmp
$2 = (sys_jmp_buf *) 0x4005cdae8 <main_thread+224>

In the help-gnu-emacs thread, Eli said:

  [...] we should ask the MinGW64 developers for advice about using
  longjmp. Most probably, something in that area has changed in recent
  releases of their runtime [...]

Eli, my apologies, but I don't think I understand the issues well
enough to have a productive discussion with the MinGW-W64 developers
myself.

[servicelistpage-1.txt (text/plain, attachment)]

[backtrace.txt (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: emacs-26 crash due to misaligned longjmp buffer in 64-bit
 MSYS2/MinGW-W64 build
Date: Sat, 28 Oct 2017 16:55:45 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Sat, 28 Oct 2017 14:40:41 +0100
> 
> In the help-gnu-emacs thread, Eli said:
> 
>   [...] we should ask the MinGW64 developers for advice about using
>   longjmp. Most probably, something in that area has changed in recent
>   releases of their runtime [...]
> 
> Eli, my apologies, but I don't think I understand the issues well
> enough to have a productive discussion with the MinGW-W64 developers
> myself.

Just ask them to read this bug report and ask questions if they don't
understand the issue well enough.

Thanks.

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

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "help-gnu-emacs <at> gnu.org" <help-gnu-emacs <at> gnu.org>, 29040 <at> debbugs.gnu.org
Subject: Re: Emacs 25 hangs on windows arbitrarily during search of a unicode
 file
Date: Sat, 28 Oct 2017 14:56:15 +0100

Eli Zaretskii <eliz <at> gnu.org> wrote:

> (And this discussion should have moved to bug-gnu-emacs ages ago.)

#29040 (CC'd).

>> (gdb) p $rax
>> $1 = 17185954536
>
> p/x $rax is usually more useful.

Much better, thank you.

> So my guess was correct, and we should ask the MinGW64 developers for
> advice about using longjmp.  Most probably, something in that area has
> changed in recent releases of their runtime, because otherwise I
> cannot explain to myself why these issues pop up only now.

I thought Paul was of a differing opinion (see
<http://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00482.html>)
but perhaps I'm mixing up different issues.

Do I take it we don't get to allocate the jmp_buf ourselves?

> Thanks.

Thanks.

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

From: Richard Copley <rcopley <at> gmail.com>
To: mingw-w64-public <at> lists.sourceforge.net, 29040 <at> debbugs.gnu.org
Subject: Trouble with misaligned jmp_buf in 64-bit MinGW-64 runtime,
 in Emacs 26
Date: Sat, 28 Oct 2017 15:10:33 +0100

Hello MinGW-W64,

I'm writing on behalf of the Emacs developers. They are keen to have
your advice on the proper way to call setjmp with the current version
of the 64-bit MinGW-W64 runtime.

I tried to summarise the current issue in Emacs bug #29040. Would you
mind having a look at the report, please?

<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29040>

I have CC'd the bug's email address on the Emacs bug tracker.

Warm regards,
Richard.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 29040 <at> debbugs.gnu.org
Subject: Re: Emacs 25 hangs on windows arbitrarily during search of a unicode
 file
Date: Sat, 28 Oct 2017 17:14:14 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Sat, 28 Oct 2017 14:56:15 +0100
> Cc: "help-gnu-emacs <at> gnu.org" <help-gnu-emacs <at> gnu.org>, 29040 <at> debbugs.gnu.org
> 
> > So my guess was correct, and we should ask the MinGW64 developers for
> > advice about using longjmp.  Most probably, something in that area has
> > changed in recent releases of their runtime, because otherwise I
> > cannot explain to myself why these issues pop up only now.
> 
> I thought Paul was of a differing opinion (see
> <http://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00482.html>)
> but perhaps I'm mixing up different issues.

I'm not saying that this is a GCC bug.  But maybe you are right, and
the changes in d7038020 exposed this problem.  I would have thought it
was the other way around: the mis-alignment should have been fixed by
those changes, but the fact that the pretest doesn't have this problem
tells otherwise.

> Do I take it we don't get to allocate the jmp_buf ourselves?

It is a member of struct thread_state, and the struct itself should be
correctly aligned on the emacs-26 branch, AFAIU.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rcopley <at> gmail.com
Cc: 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Sat, 28 Oct 2017 18:58:28 +0300

> Date: Sat, 28 Oct 2017 17:14:14 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 29040 <at> debbugs.gnu.org
> 
> I'm not saying that this is a GCC bug.  But maybe you are right, and
> the changes in d7038020 exposed this problem.

Actually, I think it was caused by 015f0bb.  Does the patch below fix
the problem?  Please actually check the alignment of getcjmp, not just
that the crashes went away.

diff --git a/src/thread.c b/src/thread.c
index 6f12d79..2520771 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -26,7 +26,11 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 #include "coding.h"
 #include "syssignal.h"
 
-static struct thread_state alignas (GCALIGNMENT) main_thread;
+#define COMMON_MULTIPLE(a, b) \
+  ((a) % (b) == 0 ? (a) : (b) % (a) == 0 ? (b) : (a) * (b))
+#define THREAD_ALIGNMENT COMMON_MULTIPLE (alignof (max_align_t), GCALIGNMENT)
+
+static struct thread_state alignas (THREAD_ALIGNMENT) main_thread;
 
 struct thread_state *current_thread = &main_thread;
 

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

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Sat, 28 Oct 2017 17:16:14 +0100

On 28 October 2017 at 16:58, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Sat, 28 Oct 2017 17:14:14 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 29040 <at> debbugs.gnu.org
>>
>> I'm not saying that this is a GCC bug.  But maybe you are right, and
>> the changes in d7038020 exposed this problem.
>
> Actually, I think it was caused by 015f0bb.  Does the patch below fix
> the problem?  Please actually check the alignment of getcjmp, not just
> that the crashes went away.
>
> diff --git a/src/thread.c b/src/thread.c
> index 6f12d79..2520771 100644
> --- a/src/thread.c
> +++ b/src/thread.c
> @@ -26,7 +26,11 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
>  #include "coding.h"
>  #include "syssignal.h"
>
> -static struct thread_state alignas (GCALIGNMENT) main_thread;
> +#define COMMON_MULTIPLE(a, b) \
> +  ((a) % (b) == 0 ? (a) : (b) % (a) == 0 ? (b) : (a) * (b))
> +#define THREAD_ALIGNMENT COMMON_MULTIPLE (alignof (max_align_t), GCALIGNMENT)
> +
> +static struct thread_state alignas (THREAD_ALIGNMENT) main_thread;
>
>  struct thread_state *current_thread = &main_thread;

Looks good. There's no crash and getcjmp is aligned:

Thread 1 hit Breakpoint 3, quit_throw_to_read_char (
    from_signal=from_signal <at> entry=false) at keyboard.c:10548
10548     sys_longjmp (getcjmp, 1);
(gdb) p &getcjmp
$1 = (sys_jmp_buf *) 0x4005cdaf0 <main_thread+224>

My message to MinGW-W64 was held up for moderation. I have cancelled it.
Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Sat, 28 Oct 2017 19:41:33 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Sat, 28 Oct 2017 17:16:14 +0100
> Cc: 29040 <at> debbugs.gnu.org
> 
> > Actually, I think it was caused by 015f0bb.  Does the patch below fix
> > the problem?  Please actually check the alignment of getcjmp, not just
> > that the crashes went away.
> >
> > diff --git a/src/thread.c b/src/thread.c
> > index 6f12d79..2520771 100644
> > --- a/src/thread.c
> > +++ b/src/thread.c
> > @@ -26,7 +26,11 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
> >  #include "coding.h"
> >  #include "syssignal.h"
> >
> > -static struct thread_state alignas (GCALIGNMENT) main_thread;
> > +#define COMMON_MULTIPLE(a, b) \
> > +  ((a) % (b) == 0 ? (a) : (b) % (a) == 0 ? (b) : (a) * (b))
> > +#define THREAD_ALIGNMENT COMMON_MULTIPLE (alignof (max_align_t), GCALIGNMENT)
> > +
> > +static struct thread_state alignas (THREAD_ALIGNMENT) main_thread;
> >
> >  struct thread_state *current_thread = &main_thread;
> 
> Looks good. There's no crash and getcjmp is aligned:
> 
> Thread 1 hit Breakpoint 3, quit_throw_to_read_char (
>     from_signal=from_signal <at> entry=false) at keyboard.c:10548
> 10548     sys_longjmp (getcjmp, 1);
> (gdb) p &getcjmp
> $1 = (sys_jmp_buf *) 0x4005cdaf0 <main_thread+224>

Thanks, I installed that.

If the problem doesn't come back, please close the bug.

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

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Sun, 29 Oct 2017 18:10:34 +0000

> If the problem doesn't come back, please close the bug.

Not sure yet. There was a crash, but no opportunity to attach
the debugger. I'm running in the debugger now but there has
not been another crash so far.

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

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 
 GNU bug tracker automated control server <control <at> debbugs.gnu.org>
Cc: 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Wed, 1 Nov 2017 19:16:48 +0000

tags 29040 fixed
close 29040
thanks

On 29 October 2017 at 18:10, Richard Copley <rcopley <at> gmail.com> wrote:
>> If the problem doesn't come back, please close the bug.
>
> Not sure yet. There was a crash, but no opportunity to attach
> the debugger. I'm running in the debugger now but there has
> not been another crash so far.

Seems fine now, probably I was mistaken.
Thanks very much.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Wed, 1 Nov 2017 23:02:39 -0700

> +#define THREAD_ALIGNMENT COMMON_MULTIPLE (alignof (max_align_t), GCALIGNMENT)
> +
> +static struct thread_state alignas (THREAD_ALIGNMENT) main_thread;

Three questions:

The Gnulib manual 
<https://www.gnu.org/software/gnulib/manual/html_node/stdalign_002eh.html> says, 
"Some compilers require the operand of _Alignas/alignas to be a single integer 
constant, not an expression: MSVC 7.0 through at least 10.0." (Also, 
<https://stackoverflow.com/questions/7895869/cross-platform-alignx-macro> 
suggests that this issue may also occur with VS2013, though VS2015 should be OK 
since it supports alignas.) Are any of these older compilers of concern when 
building Emacs? If so, the above change won't work for them.

Why does the above code use 'alignof (max_align_t)' rather than 'alignof (struct 
thread_state)'? Doesn't the latter suffice?

C11 requires that a compiler must issue a diagnostic for a declaration like 
'struct thread_state alignas (8) foo;' if the alignment of plain 'struct state' 
is greater than 8. Can I take it from this bug report that the Microsoft 
compilers do not conform to that part of the standard? If so, we should add 
checks to verify this requirement where it is assumed elsewhere.

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

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 
 GNU bug tracker automated control server <control <at> debbugs.gnu.org>
Cc: 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Thu, 2 Nov 2017 07:39:29 +0000

On 1 November 2017 at 19:16, Richard Copley <rcopley <at> gmail.com> wrote:
> tags 29040 fixed
> close 29040
> thanks
>
> On 29 October 2017 at 18:10, Richard Copley <rcopley <at> gmail.com> wrote:
>>> If the problem doesn't come back, please close the bug.
>>
>> Not sure yet. There was a crash, but no opportunity to attach
>> the debugger. I'm running in the debugger now but there has
>> not been another crash so far.
>
> Seems fine now, probably I was mistaken.

Yes. I hadn't run "make install". I was still seeing the same crash, in my
previous build.

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

From: Richard Copley <rcopley <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Thu, 2 Nov 2017 07:43:34 +0000

On 2 November 2017 at 06:02, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>> +#define THREAD_ALIGNMENT COMMON_MULTIPLE (alignof (max_align_t),
>> GCALIGNMENT)
>> +
>> +static struct thread_state alignas (THREAD_ALIGNMENT) main_thread;
>
> Three questions:
>
> The Gnulib manual
> <https://www.gnu.org/software/gnulib/manual/html_node/stdalign_002eh.html>
> says, "Some compilers require the operand of _Alignas/alignas to be a single
> integer constant, not an expression: MSVC 7.0 through at least 10.0." (Also,
> <https://stackoverflow.com/questions/7895869/cross-platform-alignx-macro>
> suggests that this issue may also occur with VS2013, though VS2015 should be
> OK since it supports alignas.) Are any of these older compilers of concern
> when building Emacs?

I don't think so. How would one go about building Emacs with MSVC anyway?

>If so, the above change won't work for them.

> Why does the above code use 'alignof (max_align_t)' rather than 'alignof
> (struct thread_state)'? Doesn't the latter suffice?

For information, in the 64-bit GCC 7.2 toolchain from MinGW-W64, the two
are equal in value.

> C11 requires that a compiler must issue a diagnostic for a declaration like
> 'struct thread_state alignas (8) foo;' if the alignment of plain 'struct
> state' is greater than 8. Can I take it from this bug report that the
> Microsoft compilers do not conform to that part of the standard?

Microsoft compilers weren't mentioned at all. GCC didn't issue
a diagnostic.

> If so, we should add checks to verify this requirement where it is assumed elsewhere.

I think that is a good idea.

Thanks.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Richard Copley <rcopley <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Thu, 02 Nov 2017 07:10:16 -0400

Richard Copley <rcopley <at> gmail.com> writes:

> I don't think so. How would one go about building Emacs with MSVC anyway?

AFAIK, it used to be possible via nt/config.bat, but we stopped
supporting it in 24.4 and removed the code for it entirely in 25.1.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Thu, 02 Nov 2017 17:50:01 +0200

> Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 1 Nov 2017 23:02:39 -0700
> 
> > +#define THREAD_ALIGNMENT COMMON_MULTIPLE (alignof (max_align_t), GCALIGNMENT)
> > +
> > +static struct thread_state alignas (THREAD_ALIGNMENT) main_thread;
> 
> Three questions:
> 
> The Gnulib manual 
> <https://www.gnu.org/software/gnulib/manual/html_node/stdalign_002eh.html> says, 
> "Some compilers require the operand of _Alignas/alignas to be a single integer 
> constant, not an expression: MSVC 7.0 through at least 10.0." (Also, 
> <https://stackoverflow.com/questions/7895869/cross-platform-alignx-macro> 
> suggests that this issue may also occur with VS2013, though VS2015 should be OK 
> since it supports alignas.) Are any of these older compilers of concern when 
> building Emacs? If so, the above change won't work for them.

We've stopped supporting MSVC long ago.  Only GCC is supported for
building on MS-Windows.

> Why does the above code use 'alignof (max_align_t)' rather than 'alignof (struct 
> thread_state)'? Doesn't the latter suffice?

No special reason, I just did the same as you did in aligning
pseudovectors, when we had a similar problem the last time.  Feel free
to change if you think it's better.

> C11 requires that a compiler must issue a diagnostic for a declaration like 
> 'struct thread_state alignas (8) foo;' if the alignment of plain 'struct state' 
> is greater than 8. Can I take it from this bug report that the Microsoft 
> compilers do not conform to that part of the standard? If so, we should add 
> checks to verify this requirement where it is assumed elsewhere.

Again, this is GCC, so what MS compilers do is not interesting.

The problem was caused by your changes in 015f0bb, which were for
OpenVMS:

  diff --git a/src/thread.c b/src/thread.c
  index c03cdda..6f12d79 100644
  --- a/src/thread.c
  +++ b/src/thread.c
  @@ -26,7 +26,7 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
   #include "coding.h"
   #include "syssignal.h"

  -static struct thread_state main_thread;
  +static struct thread_state alignas (GCALIGNMENT) main_thread;

   struct thread_state *current_thread = &main_thread;

This downgraded the alignment on 64-bit MS-Windows hosts, so I
upgraded it back.  If using alignas with an argument > 8 is
non-portable, then I guess we will have to make your OpenVMS fix
conditional on just that platform.  Or do you see a cleaner fix?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Thu, 2 Nov 2017 13:35:16 -0700

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

On 11/02/2017 08:50 AM, Eli Zaretskii wrote:
> do you see a cleaner fix?

Yes, we can stop using alignas entirely, since it doesn't work the way I 
expected. I thought that it could only increase alignment, and that it 
was a no-op if it specified a decreased alignment: this is how 
__attribute__ ((aligned (8))) works. However, I now see that C11 says 
that a compiler is supposed to report an error if alignas specifies a 
decreased alignment. So I installed the attached patch to stop using 
alignas.

> We've stopped supporting MSVC long ago.
OK. Can we then simplify the source a little bit, in the 'master' 
branch, as a low-priority task? I was thinking of something like this:

* Remove my_endbss_static in lastfile.c, since we no longer need to 
worry about the Alpha MSVC linker.

* Remove the the _MSC_VER-specific code in lisp.h's definitions of 
ENUM_BF and DEFUN and in regex.c's definition of re_char and const_re_char.

[0001-Fix-alignment-portability-problems.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Thu, 02 Nov 2017 22:46:11 +0200

> Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 2 Nov 2017 13:35:16 -0700
> 
> Yes, we can stop using alignas entirely, since it doesn't work the way I 
> expected. I thought that it could only increase alignment, and that it 
> was a no-op if it specified a decreased alignment: this is how 
> __attribute__ ((aligned (8))) works. However, I now see that C11 says 
> that a compiler is supposed to report an error if alignas specifies a 
> decreased alignment. So I installed the attached patch to stop using 
> alignas.

Thanks, but I think the resulting code is confusing.  E.g.:

  static struct thread_state GCALIGNED main_thread;

This looks like we ask main_thread to be 8-byte aligned, which would
bring back the problems we had before.  Requiring readers to read the
C Standard is not a good thing.

Can we come up with a clearer code, please?

> * Remove my_endbss_static in lastfile.c, since we no longer need to 
> worry about the Alpha MSVC linker.

I don't know anything about that code, and I don't think anyone does.
Who will tell us that the comment is still accurate?

> * Remove the the _MSC_VER-specific code in lisp.h's definitions of 
> ENUM_BF and DEFUN and in regex.c's definition of re_char and const_re_char.

I don't think ENUM_BF is only for MSVC.  The condition there mentions
other compilers.

Anything that is conditioned by _MSC_VER can go.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Thu, 2 Nov 2017 22:03:17 -0700

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

Eli Zaretskii wrote:
> Thanks, but I think the resulting code is confusing.  E.g.:
> 
>    static struct thread_state GCALIGNED main_thread;
> 
> This looks like we ask main_thread to be 8-byte aligned, which would
> bring back the problems we had before.

I attempted to clarify this by installing the first attached patch into the 
emacs-26 branch. This patch adds a comment to the definition of GCALIGNED. If 
the name "GCALIGNED" itself is confusing, we can systematically change the name 
to something else.  (The name doesn't confuse me, but perhaps I'm too close to 
the code.)

> I don't know anything about that code, and I don't think anyone does.
> Who will tell us that the comment is still accurate?

Since MSVC is no longer relevant, it doesn't matter whether the comment about 
MSVC is accurate, and we can remove it.

> Anything that is conditioned by _MSC_VER can go.

I did that by installing the second attached patch into 'master'. This affects 
only the mainline code; I didn't fiddle with the MS-Windows-only files since I 
can't easily test them.

[0001-src-lisp.h-GCALIGNED-Clarify-comment-Bug-29040.patch (text/x-patch, attachment)]

[0001-Simplify-by-assuming-_MSC_VER.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Fri, 03 Nov 2017 10:37:41 +0200

> Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 2 Nov 2017 22:03:17 -0700
> 
> > I don't know anything about that code, and I don't think anyone does.
> > Who will tell us that the comment is still accurate?
> 
> Since MSVC is no longer relevant, it doesn't matter whether the comment about 
> MSVC is accurate, and we can remove it.

Alpha was never relevant for the MS-Windows builds, either, but we
still had this code since about forever.

But my point was that I'm not sure this isn't needed for the GCC build
on Windows.  I don't know enough about how GNU ld generates MS-Windows
executables to tell whether this could be so.  If you feel strongly
about getting rid of those 2 lines, I guess it's okay to try that on
master.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Fri, 3 Nov 2017 01:48:30 -0700

Eli Zaretskii wrote:
> If you feel strongly
> about getting rid of those 2 lines, I guess it's okay to try that on
> master.

I don't feel that strongly. I left the code alone, and merely deleted the 
comment about the Alpha MSVC (which is obsolete and no longer relevant).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Fri, 03 Nov 2017 10:50:38 +0200

> Cc: rcopley <at> gmail.com, 29040 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 2 Nov 2017 22:03:17 -0700
> 
> I attempted to clarify this by installing the first attached patch into the 
> emacs-26 branch. This patch adds a comment to the definition of GCALIGNED. If 
> the name "GCALIGNED" itself is confusing, we can systematically change the name 
> to something else.  (The name doesn't confuse me, but perhaps I'm too close to 
> the code.)

Seems like this causes trouble to some versions of GCC.  Compiling the
current master on fencepost.gnu.org with GCC 4.8.4 fails with the
following diagnostic:

  In file included from lisp.h:783:0,
		   from vm-limit.c:21:
  globals.h:1095:10: error: requested alignment is not an integer constant
     struct Lisp_Symbol GCALIGNED s;
	    ^
  In file included from vm-limit.c:21:0:
  lisp.h:1149:3: error: requested alignment is not an integer constant
     };
     ^
  lisp.h:1262:3: error: requested alignment is not an integer constant
     };
     ^

This GCC identifies itself as

  $ gcc --version
  gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
  Copyright (C) 2013 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Fri, 3 Nov 2017 02:25:17 -0700

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

Eli Zaretskii wrote:
>    globals.h:1095:10: error: requested alignment is not an integer constant
>       struct Lisp_Symbol GCALIGNED s;
> 	    ^


Ouch, I had thought that only older MSVC had the problem. Sorry about that. I 
installed the attached into emacs-26 and merged it to master.

[0001-Change-GCALIGNMENT-back-to-an-integer-literal.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 29040 <at> debbugs.gnu.org
Subject: Re: bug#29040: Emacs 25 hangs on windows arbitrarily during search of
 a unicode file
Date: Fri, 03 Nov 2017 12:02:57 +0200

> Cc: 29040 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 3 Nov 2017 02:25:17 -0700
> 
> Eli Zaretskii wrote:
> >    globals.h:1095:10: error: requested alignment is not an integer constant
> >       struct Lisp_Symbol GCALIGNED s;
> > 	    ^
> 
> 
> Ouch, I had thought that only older MSVC had the problem. Sorry about that. I 
> installed the attached into emacs-26 and merged it to master.

Thanks, this fixed the build on fencepost.

Previous Next

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