bug#16264: GC crash

bug#16264: GC crash

[Juanma Barranquero]

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

bug#16264: GC crash

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@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@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.

bug#16264: GC crash

[Juanma Barranquero]

On Fri, Dec 27, 2013 at 9:12 AM, Eli Zaretskii <eliz@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

bug#16264: GC crash

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 27 Dec 2013 11:13:57 +0100
> Cc: 16264@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.

bug#16264: GC crash

[Lars Ingebrigtsen]

Juanma Barranquero <lekktu@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@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