* bug#16264: GC crash
@ 2013-12-27 3:06 Juanma Barranquero
2013-12-27 8:12 ` Eli Zaretskii
2019-10-01 16:01 ` Lars Ingebrigtsen
0 siblings, 2 replies; 5+ messages in thread
From: Juanma Barranquero @ 2013-12-27 3:06 UTC (permalink / raw)
To: 16264
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)
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16264: GC crash
2013-12-27 3:06 bug#16264: GC crash Juanma Barranquero
@ 2013-12-27 8:12 ` Eli Zaretskii
2013-12-27 10:13 ` Juanma Barranquero
2019-10-01 16:01 ` Lars Ingebrigtsen
1 sibling, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2013-12-27 8:12 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 16264
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16264: GC crash
2013-12-27 8:12 ` Eli Zaretskii
@ 2013-12-27 10:13 ` Juanma Barranquero
2013-12-27 11:13 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Juanma Barranquero @ 2013-12-27 10:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16264
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
^ permalink raw reply [flat|nested] 5+ messages in thread* bug#16264: GC crash
2013-12-27 10:13 ` Juanma Barranquero
@ 2013-12-27 11:13 ` Eli Zaretskii
0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2013-12-27 11:13 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 16264
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16264: GC crash
2013-12-27 3:06 bug#16264: GC crash Juanma Barranquero
2013-12-27 8:12 ` Eli Zaretskii
@ 2019-10-01 16:01 ` Lars Ingebrigtsen
1 sibling, 0 replies; 5+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-01 16:01 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 16264
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-10-01 16:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-27 3:06 bug#16264: GC crash Juanma Barranquero
2013-12-27 8:12 ` Eli Zaretskii
2013-12-27 10:13 ` Juanma Barranquero
2013-12-27 11:13 ` Eli Zaretskii
2019-10-01 16:01 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).