GNU bug report logs - #16264
GC crash

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 16264 in the body.
You can then email your comments to 16264 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: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: GC crash
Date: Fri, 27 Dec 2013 04:06:44 +0100

Package: emacs
Version: 24.3.50


Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 9596.0x2988]
0x76b5321a in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll
(gdb) bt
#0  0x76b5321a in KERNELBASE!DeleteAce () from
C:\Windows\syswow64\KernelBase.dll
#1  0x011fb2d2 in emacs_abort () at w32fns.c:8415
#2  0x010efd62 in terminate_due_to_signal (sig=11, backtrace_limit=40)
at emacs.c:378
#3  0x01114354 in handle_fatal_signal (sig=11) at sysdep.c:1628
#4  0x0111432f in deliver_thread_signal (sig=11, handler=0x111433b
<handle_fatal_signal>) at sysdep.c:1602
#5  0x01114388 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1640
#6  0x010011ea in _gnu_exception_handler <at> 4 ()
#7  0x011fb1fa in my_exception_handler (exception_data=0x88a388) at
w32fns.c:8365
#8  0x7698fffb in KERNEL32!GetQueuedCompletionStatus () from
C:\Windows\syswow64\kernel32.dll
#9  0x0088a388 in ?? ()
#10 0x779074ff in ntdll!AlpcMaxAllowedMessageLength () from
C:\Windows\SysWOW64\ntdll.dll
#11 0x0088a388 in ?? ()
#12 0x778c9f45 in ntdll!RtlpNtSetValueKey () from C:\Windows\SysWOW64\ntdll.dll
#13 0x011be1bd in sprintf (__stream=0x0, __format=0x0) at
c:/bin/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../include/stdio.h:269
#14 0x7efde000 in ?? ()
#15 0x00000000 in ?? ()

Lisp Backtrace:
"Automatic GC" (0x1536dfc)
"put-text-property" (0x88aaf8)
"font-lock-prepend-text-property" (0x88ae40)
0x51e1bc0 PVEC_COMPILED
"mapcar" (0x88b2f8)
"completion-hilit-commonality" (0x88b650)
"completion-basic-all-completions" (0x88b97c)
0x56ca708 PVEC_COMPILED
0x56caf50 PVEC_COMPILED
"funcall" (0x88bfe0)
"completion--some" (0x88c4e0)
"completion--nth-completion" (0x88c83c)
"completion-all-completions" (0x88cb90)
"completion-all-sorted-completions" (0x88cee8)
"icomplete-completions" (0x88d228)
"byte-code" (0x88d4c0)
"byte-code" (0x88d830)
"icomplete-exhibit" (0x88dca8)
"icomplete-minibuffer-setup" (0x88e05c)
"read-from-minibuffer" (0x88e280)
"completing-read-default" (0x88e5c0)
"completing-read" (0x88e6d4)
"byte-code" (0x88e980)
"call-interactively" (0x88ec84)
"electric-helpify" (0x88efc8)
"electric-describe-function" (0x88f314)
"call-interactively" (0x88f520)
"command-execute" (0x88f85c)
(gdb)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16264 <at> debbugs.gnu.org
Subject: Re: bug#16264: GC crash
Date: Fri, 27 Dec 2013 10:12:25 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 27 Dec 2013 04:06:44 +0100
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 9596.0x2988]
> 0x76b5321a in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll
> (gdb) bt
> #0  0x76b5321a in KERNELBASE!DeleteAce () from
> C:\Windows\syswow64\KernelBase.dll
> #1  0x011fb2d2 in emacs_abort () at w32fns.c:8415
> #2  0x010efd62 in terminate_due_to_signal (sig=11, backtrace_limit=40)
> at emacs.c:378
> #3  0x01114354 in handle_fatal_signal (sig=11) at sysdep.c:1628
> #4  0x0111432f in deliver_thread_signal (sig=11, handler=0x111433b
> <handle_fatal_signal>) at sysdep.c:1602
> #5  0x01114388 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1640
> #6  0x010011ea in _gnu_exception_handler <at> 4 ()
> #7  0x011fb1fa in my_exception_handler (exception_data=0x88a388) at
> w32fns.c:8365
> #8  0x7698fffb in KERNEL32!GetQueuedCompletionStatus () from
> C:\Windows\syswow64\kernel32.dll
> #9  0x0088a388 in ?? ()
> #10 0x779074ff in ntdll!AlpcMaxAllowedMessageLength () from
> C:\Windows\SysWOW64\ntdll.dll
> #11 0x0088a388 in ?? ()
> #12 0x778c9f45 in ntdll!RtlpNtSetValueKey () from C:\Windows\SysWOW64\ntdll.dll
> #13 0x011be1bd in sprintf (__stream=0x0, __format=0x0) at
> c:/bin/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../include/stdio.h:269
> #14 0x7efde000 in ?? ()
> #15 0x00000000 in ?? ()
> 
> Lisp Backtrace:
> "Automatic GC" (0x1536dfc)
> "put-text-property" (0x88aaf8)
> "font-lock-prepend-text-property" (0x88ae40)
> 0x51e1bc0 PVEC_COMPILED
> "mapcar" (0x88b2f8)
> "completion-hilit-commonality" (0x88b650)
> "completion-basic-all-completions" (0x88b97c)
> 0x56ca708 PVEC_COMPILED
> 0x56caf50 PVEC_COMPILED
> "funcall" (0x88bfe0)
> "completion--some" (0x88c4e0)
> "completion--nth-completion" (0x88c83c)
> "completion-all-completions" (0x88cb90)
> "completion-all-sorted-completions" (0x88cee8)
> "icomplete-completions" (0x88d228)
> "byte-code" (0x88d4c0)
> "byte-code" (0x88d830)
> "icomplete-exhibit" (0x88dca8)
> "icomplete-minibuffer-setup" (0x88e05c)
> "read-from-minibuffer" (0x88e280)
> "completing-read-default" (0x88e5c0)
> "completing-read" (0x88e6d4)
> "byte-code" (0x88e980)
> "call-interactively" (0x88ec84)
> "electric-helpify" (0x88efc8)
> "electric-describe-function" (0x88f314)
> "call-interactively" (0x88f520)
> "command-execute" (0x88f85c)
> (gdb)

Do you have the exception data printed by this code fragment in
emacs_abort:

	    if (except_addr)
	      sprintf (buf, "\r\nException 0x%lx at this address:\r\n%p\r\n",
		       except_code, except_addr);

If not, please next time examine these 2 variables, or let Emacs
continue from the abort, so it itself outputs the information.  This
is especially important when the backtrace shown by GDB doesn't show
anything useful above _gnu_exception_handler, because except_addr will
tell us which code caused the exception, and what exception was that
(Windows maps quite a few of them to SIGSEGV).

Thanks.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16264 <at> debbugs.gnu.org
Subject: Re: bug#16264: GC crash
Date: Fri, 27 Dec 2013 11:13:57 +0100

On Fri, Dec 27, 2013 at 9:12 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Do you have the exception data printed by this code fragment in
> emacs_abort:

Alas, no.

> If not, please next time examine these 2 variables, or let Emacs
> continue from the abort, so it itself outputs the information.

This happened when Emacs wasn't being run from GDB, and after gdb -p
PID and "continue", that information didn't show.

> This
> is especially important when the backtrace shown by GDB doesn't show
> anything useful above _gnu_exception_handler, because except_addr will
> tell us which code caused the exception, and what exception was that
> (Windows maps quite a few of them to SIGSEGV).

Will try to get it next time.

    J

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16264 <at> debbugs.gnu.org
Subject: Re: bug#16264: GC crash
Date: Fri, 27 Dec 2013 13:13:37 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 27 Dec 2013 11:13:57 +0100
> Cc: 16264 <at> debbugs.gnu.org
> 
> This happened when Emacs wasn't being run from GDB, and after gdb -p

Yes, I know.  If you were running Emacs from GDB, the original
exception would have been caught by GDB and reported with the full
backtrace, before _gnu_exception_handler is called.  Exception
handling on Windows is sensitive to whether the program is being
debugged or not.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 16264 <at> debbugs.gnu.org
Subject: Re: bug#16264: GC crash
Date: Tue, 01 Oct 2019 18:01:53 +0200

Juanma Barranquero <lekktu <at> gmail.com> writes:

> Package: emacs
> Version: 24.3.50
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 9596.0x2988]
> 0x76b5321a in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll
> (gdb) bt
> #0  0x76b5321a in KERNELBASE!DeleteAce () from
> C:\Windows\syswow64\KernelBase.dll
> #1  0x011fb2d2 in emacs_abort () at w32fns.c:8415
> #2  0x010efd62 in terminate_due_to_signal (sig=11, backtrace_limit=40)
> at emacs.c:378
> #3  0x01114354 in handle_fatal_signal (sig=11) at sysdep.c:1628
> #4  0x0111432f in deliver_thread_signal (sig=11, handler=0x111433b
> <handle_fatal_signal>) at sysdep.c:1602
> #5  0x01114388 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1640
> #6  0x010011ea in _gnu_exception_handler <at> 4 ()

This was five years ago, so it seems unlikely that any further progress
will be made on this crash, and I'm closing this bug report.  If you're
still seeing this problem in newer Emacs versions, please reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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