emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] bug#19606: 24.4; Emacs hangs when editing a 5-line Org file


From: Eli Zaretskii
Subject: [O] bug#19606: 24.4; Emacs hangs when editing a 5-line Org file
Date: Fri, 16 Jan 2015 10:24:51 +0200

> Date: Fri, 16 Jan 2015 00:06:58 +0300
> From: Dmitry Gutov <address@hidden>
> CC: address@hidden
> 
> 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)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]