GNU bug report logs - #29183
27.0.50; SIGSEGV on C-g on Windows

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 29183 in the body.
You can then email your comments to 29183 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: John Mastro <john.b.mastro <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; SIGSEGV on C-g on Windows
Date: Mon, 6 Nov 2017 13:58:30 -0800

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

[ 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

[bt-full.txt (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: John Mastro <john.b.mastro <at> gmail.com>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Tue, 07 Nov 2017 05:36:26 +0200

> From: John Mastro <john.b.mastro <at> 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?

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

From: John Mastro <john.b.mastro <at> gmail.com>
To: 29183 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Tue, 7 Nov 2017 10:14:09 -0800

Eli Zaretskii <eliz <at> 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 <at> entry=false) at keyboard.c:10548
10548     sys_longjmp (getcjmp, 1);
(gdb) p &getcjmp
$2 = (sys_jmp_buf *) 0x4005d1d68 <main_thread+224>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: John Mastro <john.b.mastro <at> gmail.com>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Tue, 07 Nov 2017 21:41:05 +0200

> From: John Mastro <john.b.mastro <at> gmail.com>
> Date: Tue, 7 Nov 2017 10:14:09 -0800
> Cc: Eli Zaretskii <eliz <at> gnu.org>
> 
> Eli Zaretskii <eliz <at> 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 <at> 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?

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

From: John Mastro <john.b.mastro <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Tue, 7 Nov 2017 13:24:15 -0800

Eli Zaretskii <eliz <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: John Mastro <john.b.mastro <at> gmail.com>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Wed, 08 Nov 2017 05:43:05 +0200

> From: John Mastro <john.b.mastro <at> gmail.com>
> Date: Tue, 7 Nov 2017 13:24:15 -0800
> Cc: 29183 <at> 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?

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

From: John Mastro <john.b.mastro <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Wed, 8 Nov 2017 10:35:06 -0800

Eli Zaretskii <eliz <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: John Mastro <john.b.mastro <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Wed, 08 Nov 2017 20:53:53 +0200

> From: John Mastro <john.b.mastro <at> gmail.com>
> Date: Wed, 8 Nov 2017 10:35:06 -0800
> Cc: 29183 <at> 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?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, John Mastro <john.b.mastro <at> gmail.com>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Wed, 8 Nov 2017 14:46:53 -0800

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

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

From: John Mastro <john.b.mastro <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 29183 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Wed, 8 Nov 2017 15:41:05 -0800

Paul Eggert <eggert <at> 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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: John Mastro <john.b.mastro <at> gmail.com>
Cc: 29183 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Wed, 8 Nov 2017 20:56:24 -0800

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

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.

[0001-Use-GCALIGNED-properly-for-GCC.patch (text/x-patch, attachment)]

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

From: Davor Rotim <rotim.davor <at> gmail.com>
To: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Thu, 9 Nov 2017 15:59:00 +0100

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

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)

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Davor Rotim <rotim.davor <at> gmail.com>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Thu, 09 Nov 2017 19:04:02 +0200

> From: Davor Rotim <rotim.davor <at> 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.

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

From: John Mastro <john.b.mastro <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Thu, 9 Nov 2017 09:59:00 -0800

Paul Eggert <eggert <at> 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

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

From: Davor Rotim <rotim.davor <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Thu, 9 Nov 2017 19:10:39 +0100

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

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 <at> entry=...,
infile0=infile0 <at> entry=0xbfffc340, sourcename=...,
    sourcename <at> 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

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Davor Rotim <rotim.davor <at> gmail.com>
Cc: 29183 <at> debbugs.gnu.org
Subject: Re: bug#29183: 27.0.50; SIGSEGV on C-g on Windows
Date: Fri, 01 Dec 2017 05:00:27 -0500

tags 29183 fixed
close 29183 
quit

Davor Rotim <rotim.davor <at> 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.

Previous Next

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