From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii Subject: bug#19606: 24.4; Emacs hangs when editing a 5-line Org file Date: Fri, 16 Jan 2015 10:24:51 +0200 Message-ID: <83mw5j2kvg.fsf__14138.8225405992$1421396728$gmane$org@gnu.org> References: <86mw5kktly.fsf@example.com> <86lhl32a5e.fsf@example.com> <83oapz3o89.fsf@gnu.org> <54B82BF2.8050504@yandex.ru> Reply-To: Eli Zaretskii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YC2DJ-0006Nt-Jv for emacs-orgmode@gnu.org; Fri, 16 Jan 2015 03:25:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YC2DG-0003XJ-CI for emacs-orgmode@gnu.org; Fri, 16 Jan 2015 03:25:05 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <54B82BF2.8050504@yandex.ru> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Dmitry Gutov Cc: 19606@debbugs.gnu.org, fni-news@pirilampo.org > Date: Fri, 16 Jan 2015 00:06:58 +0300 > From: Dmitry Gutov > CC: 19606@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)