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

Previous Next

Full log

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)]

Previous Next

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