GNU bug report logs - #19606
24.4; Emacs hangs when editing a 5-line Org file

Previous Next

Full log

View this message in rfc822 format

From: Fabrice Niessen <fni-news <at> pirilampo.org>
To: Eli Zaretskii <eliz <at> gnu.org>,  Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 19606 <at> debbugs.gnu.org
Subject: bug#19606: 24.4; Emacs hangs when editing a 5-line Org file
Date: Fri, 16 Jan 2015 12:27:16 +0100

Eli Zaretskii wrote:
>> Date: Fri, 16 Jan 2015 00:06:58 +0300
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> CC: 19606 <at> 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

Previous Next

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