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

Previous Next

Full log

View this message in rfc822 format

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: 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.

Previous Next

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