bug#29183: 27.0.50; SIGSEGV on C-g on Windows

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[John Mastro]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

[ Earlier today I opened bug #29180 about needing to bump
  DUMPED_HEAP_SIZE to bootstrap on MINGW64. The following is in a build
  with that patch applied, but I don't know if the two are related. ]

On master (at commit 1d8f885) on 64-bit Windows 10 I get a SIGSEGV as
soon as I hit C-g. Just "emacs -Q; C-g" is enough to trigger it.

I've attached the output of a GDB session with "bt full" ("xbacktrace"
didn't print anything). Please let me know if I can provide any further
information.

I tried to reproduce the error with an -O0 build, but it doesn't occur
then. The backtrace is from an -O2 build.

Thanks

John

[-- Attachment #2: bt-full.txt --]
[-- Type: text/plain, Size: 8357 bytes --]

$ gdb ./emacs.exe
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./emacs.exe...done.
warning: File "C:\home\jbm\src\emacs\src\.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path C:\home\jbm\src\emacs\src\.gdbinit
line to your configuration file "C:\home\jbm/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "C:\home\jbm/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
(gdb) source .gdbinit
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x4000a81c0: file emacs.c, line 363.
Temporary breakpoint 2 at 0x4000c0cc0: init_sys_modes. (3 locations)
(gdb) r -Q
Starting program: C:\home\jbm\src\emacs\src\emacs.exe -Q
[New Thread 3240.0x3738]
[New Thread 3240.0x40ec]
[New Thread 3240.0x3490]
[New Thread 3240.0x2108]
[New Thread 3240.0x28bc]
[New Thread 3240.0x33e0]

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ff8cb7893a0 in ntdll!RtlCaptureContext ()
   from C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt full
#0  0x00007ff8cb7893a0 in ntdll!RtlCaptureContext ()
   from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x00007ff8cb6f8f27 in ntdll!RtlUnwindEx ()
   from C:\Windows\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0x00007ff8c91d1f4a in msvcrt!_setjmpex ()
   from C:\Windows\System32\msvcrt.dll
No symbol table info available.
#3  0x00000004000a93d4 in quit_throw_to_read_char (
    from_signal=from_signal@entry=false) at keyboard.c:10548
No locals.
#4  0x00000004000b4853 in kbd_buffer_get_event (end_time=0x0,
    used_mouse_menu=0xbff5b0, kbp=<synthetic pointer>) at keyboard.c:3790
        obj = <optimized out>
#5  read_event_from_main_queue (used_mouse_menu=<optimized out>,
    local_getcjmp=<optimized out>, end_time=<optimized out>)
    at keyboard.c:2151
        c = XIL(0)
        save_jump = {{
            Part = {0, 0}
          } <repeats 16 times>}
        kb = <optimized out>
#6  read_decoded_event_from_main_queue (used_mouse_menu=<optimized out>,
    local_getcjmp=<optimized out>, end_time=<optimized out>, prev_event=...)
    at keyboard.c:2214
No locals.
#7  read_char (commandflag=<optimized out>, commandflag@entry=1,
    map=XIL(0x1f00000000), map@entry=XIL(0x4006f4c03),
    prev_event=XIL(0xbff5b8), used_mouse_menu=<optimized out>,
    used_mouse_menu@entry=0xbff46b, end_time=<optimized out>,
    end_time@entry=0x0) at keyboard.c:2802
        c = <optimized out>
        jmpcount = <optimized out>
        local_getcjmp = {{
            Part = {12579656, 0}
          }, {
            Part = {12578352, 12579656}
          }, {
            Part = {17185481664, 0}
          }, {
            Part = {0, 7923139}
          }, {
            Part = {17185159176, 0}
          }, {
            Part = {17180599850, 3843995738016}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }}
        save_jump = {{
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 0}
          }, {
            Part = {0, 120}
          }, {
            Part = {17185159176, 120}
          }, {
            Part = {17185159176, 12579296}
          }, {
            Part = {17185881888, 0}
          }, {
            Part = {0, 17181019941}
          }, {
            Part = {0, 0}
          }, {
            Part = {4, 0}
          }, {
            Part = {5, 34496}
          }, {
            Part = {17188623920, 1}
          }, {
            Part = {17187559952, 17180947715}
          }, {
            Part = {1, 3}
          }, {
            Part = {1, 37408}
          }, {
            Part = {17187560176, 17180641615}
          }}
        tem = <optimized out>
        save = <optimized out>
        previous_echo_area_message = XIL(0)
        also_record = XIL(0)
        reread = false
        recorded = false
        polling_stopped_here = true
        orig_kboard = <optimized out>
#8  0x00000004000b58d2 in read_key_sequence (keybuf=keybuf@entry=0xbff5b0,
    prompt=prompt@entry=XIL(0),
    dont_downcase_last=dont_downcase_last@entry=false,
    can_return_switch_frame=can_return_switch_frame@entry=true,
    fix_current_buffer=fix_current_buffer@entry=true,
    prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at keyboard.c:9147
        interrupted_kboard = 0x2536490
        interrupted_frame = 0x400a10f00 <dumped_data+4385792>
        key = <optimized out>
        used_mouse_menu = false
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        new_binding = <optimized out>
        t = 0
        echo_start = 0
        keys_start = 0
        current_binding = XIL(0x4006f4c03)
        first_event = XIL(0)
        first_unbound = 31
        mock_input = 0
        fkey = {
          parent = XIL(0x4006eec83),
          map = XIL(0x4006eec83),
          start = 0,
          end = 0
        }
        keytran = {
          parent = XIL(0x400606293),
          map = XIL(0x400606293),
          start = 0,
          end = 0
        }
        indec = {
          parent = XIL(0x4006eeca3),
          map = XIL(0x4006eeca3),
          start = 0,
          end = 0
        }
        shift_translated = false
        delayed_switch_frame = XIL(0)
        original_uppercase = XIL(0)
        original_uppercase_position = -1
        dummyflag = false
        fake_prefixed_keys = XIL(0)
#9  0x00000004000b7371 in command_loop_1 () at keyboard.c:1368
        cmd = XIL(0x4000ad920)
        keybuf = {XIL(0xbff640), XIL(0x40011b321), XIL(0x4002f2345), XIL(0),
          XIL(0x4), XIL(0x5f004d00450054), XIL(0x46004500520050),
          XIL(0x580049), XIL(0x40900001001), XIL(0x400000004), XIL(0),
          XIL(0x7ff8c8ce25e0), XIL(0x9), make_number(43044382448936),
          XIL(0xb0000), XIL(0x78), XIL(0x40050b808), XIL(0x78),
          XIL(0x40050b808), XIL(0xbff690), XIL(0x4005bbf20), XIL(0),
          XIL(0x40064feb3), XIL(0x400118f25), XIL(0), XIL(0x3),
          XIL(0x40078f643), make_number(1000), XIL(0x5), XIL(0x8c00)}
        i = <optimized out>
        prev_modiff = 0
        prev_buffer = 0x0
#10 0x000000040011862d in internal_condition_case (
    bfun=bfun@entry=0x4000b7120 <command_loop_1>, handlers=...,
    handlers@entry=XIL(0x5b70), hfun=hfun@entry=0x4000ad920 <cmd_error>)
    at eval.c:1332
        val = XIL(0x4005d1d68)
        c = 0x2533350
#11 0x00000004000a8824 in command_loop_2 (ignore=...) at keyboard.c:1110
        val = <optimized out>
#12 0x000000040011859b in internal_catch (tag=..., tag@entry=XIL(0xf378),
    func=func@entry=0x4000a8800 <command_loop_2>, arg=arg@entry=XIL(0))
    at eval.c:1097
        val = XIL(0x4005d1d68)
        c = 0x25331c0
#13 0x00000004000a87ae in command_loop () at keyboard.c:1089
No locals.
#14 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) xbacktrace
(gdb)

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[Eli Zaretskii]

> From: John Mastro <john.b.mastro@gmail.com>
> Date: Mon, 6 Nov 2017 13:58:30 -0800
> 
> On master (at commit 1d8f885) on 64-bit Windows 10 I get a SIGSEGV as
> soon as I hit C-g. Just "emacs -Q; C-g" is enough to trigger it.
> 
> I've attached the output of a GDB session with "bt full" ("xbacktrace"
> didn't print anything). Please let me know if I can provide any further
> information.
> 
> I tried to reproduce the error with an -O0 build, but it doesn't occur
> then. The backtrace is from an -O2 build.

Is this again bug#29040?  Did main_thread become mis-aligned again?

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[John Mastro]

Eli Zaretskii <eliz@gnu.org> wrote:
> Is this again bug#29040?  Did main_thread become mis-aligned again?

I repeated the commands Richard used in that bug report, and I believe
you're right: it's 8-byte aligned rather than 16-byte aligned.
Transcript below.

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ff8cb7893a0 in ntdll!RtlCaptureContext ()
   from C:\Windows\SYSTEM32\ntdll.dll
(gdb) frame 0
#0  0x00007ff8cb7893a0 in ntdll!RtlCaptureContext ()
   from C:\Windows\SYSTEM32\ntdll.dll
(gdb) p/x $rax
$1 = 0x4005d1d68
(gdb) up
#1  0x00007ff8cb6f8f27 in ntdll!RtlUnwindEx ()
   from C:\Windows\SYSTEM32\ntdll.dll
(gdb) up
#2  0x00007ff8c91d1f4a in msvcrt!_setjmpex ()
   from C:\Windows\System32\msvcrt.dll
(gdb) up
#3  0x00000004000a93d4 in quit_throw_to_read_char (
    from_signal=from_signal@entry=false) at keyboard.c:10548
10548     sys_longjmp (getcjmp, 1);
(gdb) p &getcjmp
$2 = (sys_jmp_buf *) 0x4005d1d68 <main_thread+224>

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[Eli Zaretskii]

> From: John Mastro <john.b.mastro@gmail.com>
> Date: Tue, 7 Nov 2017 10:14:09 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> Eli Zaretskii <eliz@gnu.org> wrote:
> > Is this again bug#29040?  Did main_thread become mis-aligned again?
> 
> I repeated the commands Richard used in that bug report, and I believe
> you're right: it's 8-byte aligned rather than 16-byte aligned.
> Transcript below.
> 
> Thread 1 received signal SIGSEGV, Segmentation fault.
> 0x00007ff8cb7893a0 in ntdll!RtlCaptureContext ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> (gdb) frame 0
> #0  0x00007ff8cb7893a0 in ntdll!RtlCaptureContext ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> (gdb) p/x $rax
> $1 = 0x4005d1d68
> (gdb) up
> #1  0x00007ff8cb6f8f27 in ntdll!RtlUnwindEx ()
>    from C:\Windows\SYSTEM32\ntdll.dll
> (gdb) up
> #2  0x00007ff8c91d1f4a in msvcrt!_setjmpex ()
>    from C:\Windows\System32\msvcrt.dll
> (gdb) up
> #3  0x00000004000a93d4 in quit_throw_to_read_char (
>     from_signal=from_signal@entry=false) at keyboard.c:10548
> 10548     sys_longjmp (getcjmp, 1);
> (gdb) p &getcjmp
> $2 = (sys_jmp_buf *) 0x4005d1d68 <main_thread+224>

Yep.  How did that happen?..

Can you show a preprocessed version of thread.c, where it does this:

  static struct thread_state GCALIGNED main_thread;

Also, what is your GCC version?

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[John Mastro]

Eli Zaretskii <eliz@gnu.org> wrote:
>> > Is this again bug#29040?  Did main_thread become mis-aligned again?
>> I repeated the commands Richard used in that bug report, and I believe
>> you're right: it's 8-byte aligned rather than 16-byte aligned.
>> Transcript below.
> Yep.  How did that happen?..
>
> Can you show a preprocessed version of thread.c, where it does this:
>
>   static struct thread_state GCALIGNED main_thread;

What's the right invocation to get that? I tried some variations on:

gcc -E -mtune=generic -l/mingw64/include -l/c/home/jbm/src/emacs
-l/c/home/jbm/src/emacs/src -l/c/home/jbm/src/emacs/nt/inc src/thread.c

But always got an error:

src/thread.c:20:10: fatal error: config.h: No such file or directory

> Also, what is your GCC version?

$ gcc --version
gcc.exe (Rev1, Built by MSYS2 project) 7.2.0

Thanks

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[Eli Zaretskii]

> From: John Mastro <john.b.mastro@gmail.com>
> Date: Tue, 7 Nov 2017 13:24:15 -0800
> Cc: 29183@debbugs.gnu.org
> 
> > Can you show a preprocessed version of thread.c, where it does this:
> >
> >   static struct thread_state GCALIGNED main_thread;
> 
> What's the right invocation to get that?

You need to display it first.  Like this:

 $ cd src
 $ make thread.o -W thread.c V=1

This will compile thread.c and show the full command it uses to do
that.  Copy-paste that command at the shell prompt, but this time
replace -c (or add if -c is not there) with -E, and also add
"-o thread.ii" to the command line.  Then hit Enter.  The file
thread.ii will have the preprocessed source.

> $ gcc --version
> gcc.exe (Rev1, Built by MSYS2 project) 7.2.0

Should be okay, I think.  Does the problem go away if you remove
GCALIGNED from that line in thread.c and rebuild?

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[John Mastro]

Eli Zaretskii <eliz@gnu.org> wrote:
>> > Can you show a preprocessed version of thread.c, where it does this:
>> >
>> >   static struct thread_state GCALIGNED main_thread;
>>
>> What's the right invocation to get that?
>
> You need to display it first.  Like this:
>
>  $ cd src
>  $ make thread.o -W thread.c V=1
>
> This will compile thread.c and show the full command it uses to do
> that.  Copy-paste that command at the shell prompt, but this time
> replace -c (or add if -c is not there) with -E, and also add
> "-o thread.ii" to the command line.  Then hit Enter.  The file
> thread.ii will have the preprocessed source.

Ah, thanks. After preprocessing, that line becomes:

static struct thread_state __attribute__ ((aligned (8))) main_thread;

>> $ gcc --version
>> gcc.exe (Rev1, Built by MSYS2 project) 7.2.0
>
> Should be okay, I think.  Does the problem go away if you remove
> GCALIGNED from that line in thread.c and rebuild?

Yep, the SIGSEGV is gone if I remove GCALIGNED from that line.

Thanks

        John

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[Eli Zaretskii]

> From: John Mastro <john.b.mastro@gmail.com>
> Date: Wed, 8 Nov 2017 10:35:06 -0800
> Cc: 29183@debbugs.gnu.org
> 
> Ah, thanks. After preprocessing, that line becomes:
> 
> static struct thread_state __attribute__ ((aligned (8))) main_thread;

That's what it should have become...

> >> $ gcc --version
> >> gcc.exe (Rev1, Built by MSYS2 project) 7.2.0
> >
> > Should be okay, I think.  Does the problem go away if you remove
> > GCALIGNED from that line in thread.c and rebuild?
> 
> Yep, the SIGSEGV is gone if I remove GCALIGNED from that line.

Hmm... so it sounds like our assumption that this attribute should be
a no-op in this case is incorrect, or maybe it's a bug in GCC 7.2?
Paul?

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[Paul Eggert]

On 11/08/2017 10:53 AM, Eli Zaretskii wrote:
> it sounds like our assumption that this attribute should be a no-op in 
> this case is incorrect, or maybe it's a bug in GCC 7.2? 

The GCC 7.2 documentation 
<https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Common-Variable-Attributes.html#index-aligned-variable-attribute> 
says:

> When used on a struct, or struct member, the |aligned| attribute can 
> only increase the alignment; in order to decrease it, the |packed| 
> attribute must be specified as well.

so it appears to be a bug.

What is the difference in assembly-language output when you compile with 
this:

   static struct thread_state GCALIGNED main_thread;

versus this?

   static struct thread_state main_thread;

What is the assembly-language output when compiling the following little program, when compiled the same way that you compile thread.c?

   struct thread_state { int x; };
   static struct thread_state __attribute__ ((aligned (8))) a;
   static struct thread_state b;
   struct thread_state *c[] = { &a, &b };

On my platform, compiling this with gcc -S yields the following, which looks properly aligned:

	.file	"t.c"
	.local	a
	.comm	a,4,8
	.local	b
	.comm	b,4,4
	.globl	c
	.data
	.align 16
	.type	c, @object
	.size	c, 16
c:
	.quad	a
	.quad	b
	.ident	"GCC: (GNU) 7.2.1 20170915 (Red Hat 7.2.1-2)"
	.section	.note.GNU-stack,"",@progbits

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[John Mastro]

Paul Eggert <eggert@cs.ucla.edu> wrote:
> What is the difference in assembly-language output when you compile with
> this:
>
>   static struct thread_state GCALIGNED main_thread;
>
> versus this?
>
>   static struct thread_state main_thread;

I don't know/read assembly, so I'm not sure if this is what you're
looking for, but the only line in the diff between the two resulting
files that mentions main_thread is that the output from the source with
GCALIGNED says:

    .lcomm main_thread,592,8

Whereas the assembly output from the source without GCALIGNED says:

    .lcomm main_thread,592,32

The diff is quite large though, 3,685 lines. Almost all of them are
either ".uleb128" or ".long" followed by an operand (the operand being
what differs).

> What is the assembly-language output when compiling the following little
> program, when compiled the same way that you compile thread.c?
>
>   struct thread_state { int x; };
>   static struct thread_state __attribute__ ((aligned (8))) a;
>   static struct thread_state b;
>   struct thread_state *c[] = { &a, &b };
>
> On my platform, compiling this with gcc -S yields the following, which looks
> properly aligned:
>
>         .file   "t.c"
>         .local  a
>         .comm   a,4,8
>         .local  b
>         .comm   b,4,4
>         .globl  c
>         .data
>         .align 16
>         .type   c, @object
>         .size   c, 16
> c:
>         .quad   a
>         .quad   b
>         .ident  "GCC: (GNU) 7.2.1 20170915 (Red Hat 7.2.1-2)"
>         .section        .note.GNU-stack,"",@progbits

I get the following:

        .file  "t.c"
        .text
.Ltext0:
        .cfi_sections  .debug_frame
        .globl c
        .data
        .align 16
c:
        .quad  a
        .quad  b
.lcomm b,4,4
.lcomm a,4,8
        .text
.Letext0:
        .file 1 "t.c"
        .section        .debug_info,"dr"
[... a bunch of .Ldebug_* sections ...]
.Ldebug_line0:
        .section        .debug_str,"dr"
        .ident "GCC: (Rev1, Built by MSYS2 project) 7.2.0"

Let me know if I can provide any other information.

        John

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

John Mastro wrote:
> the only line in the diff between the two resulting
> files that mentions main_thread is that the output from the source with
> GCALIGNED says:
> 
>      .lcomm main_thread,592,8
> 
> Whereas the assembly output from the source without GCALIGNED says:
> 
>      .lcomm main_thread,592,32

Thanks, this helped me see the problem. It turns out that 'struct foo 
__attribute__ ((aligned (8)))' does not work with GCC, and that one must put the 
attribute somewhere else. This appears to be a bug in GCC, and I reported the 
GCC bug here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914

The workaround is easy: say 'struct __attribute__ ((aligned (8))) foo' instead. 
I installed the attached patch into the emacs-26 branch and merged it into 
master. Please give it a try.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-GCALIGNED-properly-for-GCC.patch --]
[-- Type: text/x-patch; name="0001-Use-GCALIGNED-properly-for-GCC.patch", Size: 4831 bytes --]

From 9e59de9449b53c3ecd85b624c11360ba9cafee75 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 8 Nov 2017 19:11:18 -0800
Subject: [PATCH] Use GCALIGNED properly for GCC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Apparently GCC requires that ‘__attribute__ ((aligned (8)))’ must
immediately follow the ‘struct’ keyword when aligning a structure.
The attribute silently does not work if it follows a tag after the
‘struct’ keyword.  Who knew?  Anyway, this patch is designed to
fix a SIGSEGV problem reported by John Mastro (Bug#29183).
* lib-src/make-docfile.c (close_emacs_globals):
* src/buffer.c (buffer_defaults, buffer_local_symbols):
* src/lisp.h (DEFUN):
* src/thread.c (main_thread):
Put 'GCALIGNED' immediately after 'struct'.
---
 lib-src/make-docfile.c |  2 +-
 src/buffer.c           |  4 ++--
 src/lisp.h             | 16 ++++++++++------
 src/thread.c           |  2 +-
 4 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/lib-src/make-docfile.c b/lib-src/make-docfile.c
index 0ea3f7b..ff84df9 100644
--- a/lib-src/make-docfile.c
+++ b/lib-src/make-docfile.c
@@ -668,7 +668,7 @@ close_emacs_globals (ptrdiff_t num_symbols)
 	   "extern\n"
 	   "#endif\n"
 	   "struct {\n"
-	   "  struct Lisp_Symbol GCALIGNED s;\n"
+	   "  struct GCALIGNED Lisp_Symbol s;\n"
 	   "} lispsym[%td];\n"),
 	  num_symbols);
 }
diff --git a/src/buffer.c b/src/buffer.c
index 15735a2..edeed55 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -61,7 +61,7 @@ struct buffer *all_buffers;
    Setting the default value also goes through the alist of buffers
    and stores into each buffer that does not say it has a local value.  */
 
-struct buffer GCALIGNED buffer_defaults;
+struct GCALIGNED buffer buffer_defaults;
 
 /* This structure marks which slots in a buffer have corresponding
    default values in buffer_defaults.
@@ -84,7 +84,7 @@ struct buffer buffer_local_flags;
 /* This structure holds the names of symbols whose values may be
    buffer-local.  It is indexed and accessed in the same way as the above.  */
 
-struct buffer GCALIGNED buffer_local_symbols;
+struct GCALIGNED buffer buffer_local_symbols;
 
 /* Return the symbol of the per-buffer variable at offset OFFSET in
    the buffer structure.  */
diff --git a/src/lisp.h b/src/lisp.h
index 4dd4720..0153468 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -277,10 +277,14 @@ DEFINE_GDB_SYMBOL_END (VALMASK)
 error !;
 #endif
 
-/* Declare an object to have an address that is a multiple of
-   GCALIGNMENT.  This is a no-op if the object's natural alignment is
-   already a multiple of GCALIGNMENT.  alignas is not suitable here,
-   as it fails if the object's natural alignment exceeds GCALIGNMENT.  */
+/* Use GCALIGNED immediately after the 'struct' keyword to require the
+   struct to have an address that is a multiple of GCALIGNMENT.  This
+   is a no-op if the struct's natural alignment is already a multiple
+   of GCALIGNMENT.  GCALIGNED's implementation uses the 'aligned'
+   attribute instead of 'alignas (GCALIGNMENT)', as the latter would
+   fail if an object's natural alignment exceeds GCALIGNMENT.  The
+   implementation hopes that natural alignment suffices on platforms
+   lacking 'aligned'.  */
 #ifdef HAVE_STRUCT_ATTRIBUTE_ALIGNED
 # define GCALIGNED __attribute__ ((aligned (GCALIGNMENT)))
 #else
@@ -2944,7 +2948,7 @@ CHECK_NUMBER_CDR (Lisp_Object x)
 #ifdef _MSC_VER
 #define DEFUN(lname, fnname, sname, minargs, maxargs, intspec, doc)	\
    Lisp_Object fnname DEFUN_ARGS_ ## maxargs ;				\
-   static struct Lisp_Subr GCALIGNED sname =				\
+   static struct GCALIGNED Lisp_Subr sname =				\
    { { (PVEC_SUBR << PSEUDOVECTOR_AREA_BITS)				\
        | (sizeof (struct Lisp_Subr) / sizeof (EMACS_INT)) },		\
       { (Lisp_Object (__cdecl *)(void))fnname },                        \
@@ -2952,7 +2956,7 @@ CHECK_NUMBER_CDR (Lisp_Object x)
    Lisp_Object fnname
 #else  /* not _MSC_VER */
 #define DEFUN(lname, fnname, sname, minargs, maxargs, intspec, doc)	\
-   static struct Lisp_Subr GCALIGNED sname =				\
+   static struct GCALIGNED Lisp_Subr sname =				\
      { { PVEC_SUBR << PSEUDOVECTOR_AREA_BITS },				\
        { .a ## maxargs = fnname },					\
        minargs, maxargs, lname, intspec, 0};				\
diff --git a/src/thread.c b/src/thread.c
index 03f5b31..7335833 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 GCALIGNED main_thread;
+static struct GCALIGNED thread_state main_thread;
 
 struct thread_state *current_thread = &main_thread;
 
-- 
2.7.4

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[John Mastro]

Paul Eggert <eggert@cs.ucla.edu> wrote:
> John Mastro wrote:
>>
>> the only line in the diff between the two resulting
>> files that mentions main_thread is that the output from the source with
>> GCALIGNED says:
>>
>>      .lcomm main_thread,592,8
>>
>> Whereas the assembly output from the source without GCALIGNED says:
>>
>>      .lcomm main_thread,592,32
>
>
> Thanks, this helped me see the problem. It turns out that 'struct foo
> __attribute__ ((aligned (8)))' does not work with GCC, and that one must put
> the attribute somewhere else. This appears to be a bug in GCC, and I
> reported the GCC bug here:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914
>
> The workaround is easy: say 'struct __attribute__ ((aligned (8))) foo'
> instead. I installed the attached patch into the emacs-26 branch and merged
> it into master. Please give it a try.

I can confirm that fixed it. Thank you both!

        John

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[Davor Rotim]

[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]

Hello,

after this patch on the emacs-26 branch I can't build it no more:

  CCLD     temacs
/bin/mkdir -p ../etc
make -C ../lisp update-subdirs
make[2]: Entering directory '/home/drot/build/emacs/lisp'
make[2]: Leaving directory '/home/drot/build/emacs/lisp'
./temacs --batch  --load loadup bootstrap
Loading loadup.el (source)...
Using load-path (/home/drot/build/emacs/lisp
/home/drot/build/emacs/lisp/emacs-lisp
/home/drot/build/emacs/lisp/progmodes /home/drot/build/emacs/lisp/language
/home/drot/build/emacs/lisp/international
/home/drot/build/emacs/lisp/textmodes /home/drot/build/emacs/lisp/vc)
Loading emacs-lisp/byte-run (source)...
Loading emacs-lisp/backquote (source)...
Loading subr (source)...
Fatal error 6: Aborted
Backtrace:
./temacs[0x81624a5]
./temacs[0x81431ea]
./temacs[0x816255f]
./temacs[0x81acea1]
./temacs[0x81acb91]
./temacs[0x81ad4f9]
./temacs[0x81cd0c9]
./temacs[0x81cd98e]
./temacs[0x81cf682]
./temacs[0x81cd673]
./temacs[0x81cd98e]
./temacs[0x81ce1ff]
./temacs[0x81cd673]
./temacs[0x81cd98e]
./temacs[0x81cde01]
./temacs[0x81cdfa6]
./temacs[0x81cd2bc]
./temacs[0x81ce38e]
./temacs[0x81cd673]
./temacs[0x81cd98e]
./temacs[0x81cea3a]
./temacs[0x81cd673]
./temacs[0x81cd98e]
./temacs[0x81cf682]
./temacs[0x81cd673]
./temacs[0x81cd98e]
./temacs[0x81ce1ff]
./temacs[0x81cd673]
./temacs[0x81cd98e]
./temacs[0x81cde01]
./temacs[0x81cdfa6]
./temacs[0x81cd2bc]
./temacs[0x81ce38e]
./temacs[0x81cd673]
./temacs[0x81cd98e]
./temacs[0x81cea3a]
./temacs[0x81cd673]
./temacs[0x81cd98e]
./temacs[0x81cf682]
./temacs[0x81cd673]
./temacs[0x81cd98e]
./temacs[0x81ce1ff]
./temacs[0x81cd673]
./temacs[0x81cd98e]
./temacs[0x81cde01]
./temacs[0x81cdfa6]
./temacs[0x81cd2bc]
./temacs[0x81cd461]
./temacs[0x81cd98e]
./temacs[0x81cde01]
./temacs[0x81ca9f6]
./temacs[0x81cce33]
./temacs[0x81ccfa3]
./temacs[0x81cd359]
./temacs[0x81cd98e]
./temacs[0x81cde01]
...
Makefile:737: recipe for target 'bootstrap-emacs' failed
make[1]: *** [bootstrap-emacs] Aborted
make[1]: Leaving directory '/home/drot/build/emacs/src'
Makefile:416: recipe for target 'src' failed
make: *** [src] Error 2

This is with the following GCC version:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/7/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-12'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-targets=all --enable-multiarch
--disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 7.2.1 20171025 (Debian 7.2.0-12)

[-- Attachment #2: Type: text/html, Size: 3662 bytes --]

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[Eli Zaretskii]

> From: Davor Rotim <rotim.davor@gmail.com>
> Date: Thu, 9 Nov 2017 15:59:00 +0100
> 
> after this patch on the emacs-26 branch I can't build it no more:

Can you run the faulting command ("./temacs --batch --load loadup
bootstrap") under a debugger, and when it aborts, show the backtrace?

Thanks.

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[Davor Rotim]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

Hello,

the backtrace:

#0  0xb7fd9ce9 in __kernel_vsyscall ()
#1  0xb61d0311 in __libc_signal_restore_set (set=0xbfffbe1c) at
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  0xb61d0311 in raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0x08139059 in terminate_due_to_signal (sig=6, backtrace_limit=40) at
emacs.c:394
#4  0x08155568 in emacs_abort () at sysdep.c:2426
#5  0x0819acea in mark_object (arg=...) at alloc.c:6742
#6  0x0819aa01 in mark_object (arg=...) at alloc.c:6651
#7  0x0819b0df in mark_vectorlike (ptr=0x8585010 <bss_sbrk_buffer+291728>)
at alloc.c:6239
#8  0x0819a980 in mark_object (arg=...) at alloc.c:6636
#9  0x0819b3d7 in garbage_collect_1 (end=<optimized out>) at alloc.c:6003
#10 0x0819b3d7 in Fgarbage_collect () at alloc.c:6180
#11 0x081b7cdc in maybe_gc () at lisp.h:4750
#12 0x081b7cdc in eval_sub (form=...) at eval.c:2139
#13 0x081de9a6 in readevalloop (readcharfun=readcharfun@entry=...,
infile0=infile0@entry=0xbfffc340, sourcename=...,
    sourcename@entry=..., printflag=false, unibyte=..., readfun=...,
start=..., end=...) at lread.c:2038
#14 0x081df40d in Fload (file=..., noerror=..., nomessage=...,
nosuffix=..., must_suffix=...) at lread.c:1425
#15 0x081b80ab in eval_sub (form=...) at eval.c:2255
#16 0x081ba19d in Feval (form=..., lexical=...) at eval.c:2051
#17 0x08139668 in top_level_2 () at keyboard.c:1119
#18 0x081b4a43 in internal_condition_case (bfun=0x8139640 <top_level_2>,
handlers=..., hfun=0x813eb60 <cmd_error>) at eval.c:1332
#19 0x08139625 in top_level_1 (ignore=...) at keyboard.c:1127
#20 0x081b4977 in internal_catch (tag=..., func=0x8139590 <top_level_1>,
arg=...) at eval.c:1097
#21 0x081394c0 in command_loop () at keyboard.c:1088
#22 0x0813e6d3 in recursive_edit_1 () at keyboard.c:695
#23 0x0813ea76 in Frecursive_edit () at keyboard.c:766
#24 0x0805b553 in main (argc=<optimized out>, argv=<optimized out>) at
emacs.c:1713

[-- Attachment #2: Type: text/html, Size: 2142 bytes --]

bug#29183: 27.0.50; SIGSEGV on C-g on Windows

[Noam Postavsky]

tags 29183 fixed
close 29183 
quit

Davor Rotim <rotim.davor@gmail.com> writes:

> after this patch on the emacs-26 branch I can't build it no more:

The original bug is fixed, so I'm closing this report.  If you still
have trouble (I think there were several more fixes following the patch
posted here) please open a new bug.