From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabrice Niessen Subject: bug#19606: 24.4; Emacs hangs when editing a 5-line Org file Date: Fri, 16 Jan 2015 12:27:16 +0100 Message-ID: <867fwnynhn.fsf__41926.9706159413$1421407725$gmane$org@example.com> References: <86mw5kktly.fsf@example.com> <86lhl32a5e.fsf@example.com> <83oapz3o89.fsf@gnu.org> <54B82BF2.8050504@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Return-path: Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: (Eli Zaretskii's message of "Fri, 16 Jan 2015 10:24:51 +0200") 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-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: Eli Zaretskii , Dmitry Gutov Cc: 19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org Eli Zaretskii wrote: >> Date: Fri, 16 Jan 2015 00:06:58 +0300 >> From: Dmitry Gutov >> CC: 19606-ubl+/3LiMTaZdePnXv/OxA@public.gmane.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