Eli Zaretskii wrote: >> Date: Fri, 16 Jan 2015 00:06:58 +0300 >> From: Dmitry Gutov <dgu...@yandex.ru> >> CC: 19...@debbugs.gnu.org >> >> On 01/15/2015 09:14 PM, Eli Zaretskii wrote: >> >>> But you didn't even show the backtrace from the main (a.k.a. "Lisp") >>> thread. Your backtrace is from thread 15, whereas the main thread >>> is thread 1. >> >> The output is from 'thread apply all backtrace', AFAICS. > > No, the output is only from threads 15 and 14. The command "thread > apply all backtrace" was indeed issued, but Emacs crashed or exited > abnormally while producing the Lisp-level backtrace for thread 14: > > [Inferior 1 (process 1204) exited with code 01] > (gdb) The program being debugged exited while in a function called > from GDB. > Evaluation of the expression containing the function > (backtrace_top) will be abandoned. > > Therefore that command didn't produce backtraces of the rest of the > threads. > > The backtraces shown are not interesting: thread 15 is a thread > created by Windows for attaching the debugger, so it doesn't belong to > Emacs; and thread 14 is the file-notification thread started by > w32notify.c, which simply sleeps waiting for file events. So the > interesting information from the main thread is not presented, and > it's therefore impossible to tell where and why Emacs hanged. > > Typing "thread 1" explicitly right after attaching to the process > might have produce the C-level backtrace for the main thread. It is a > good thing to do in any case when attaching to Emacs process that's in > trouble. > >> On the other hand, it's not 'bt full' or `xbacktrace', which >> report-emacs-bug asks to call. > > "xbacktrace" is automatically called after the C-level backtrace, when > you start GDB from the Emacs's src directory, where .gdbinit file > arranges for that. That's why you see this part in the OP: > > Lisp Backtrace: > "redisplay_internal (C function)" (0x1407e78) > "redisplay" (0x88f254) > "sit-for" (0x88f3a8) > "flyspell-check-word-p" (0x88f4f8) > "byte-code" (0x88f610) > "flyspell-post-command-hook" (0x88f844)
OK, so I just reproduced the problem once again, then: - tried to C-g in Emacs: impossible! - launched GDB - source ~/.gdbinit - thread 1 - thread apply all backtrace Still, the backtrace is not as long as normal, and I don't get any GDB prompt anymore! I tried to C-c in the shell window, as well without success... What can I do to provide you with more context? Best regards, Fabrice