From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: still seeing semi-regular lockups Date: Wed, 04 Jun 2014 12:47:09 +0800 Message-ID: <87r435wab6.fsf@ericabrahamsen.net> References: <87siocrbyb.fsf@ericabrahamsen.net> <87siobtn1i.fsf@bzg.ath.cx> <87ha4r1j91.fsf@tanger.home> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws33H-0008LV-F8 for emacs-orgmode@gnu.org; Wed, 04 Jun 2014 00:43:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ws33A-0002Hf-GF for emacs-orgmode@gnu.org; Wed, 04 Jun 2014 00:43:51 -0400 Received: from plane.gmane.org ([80.91.229.3]:41295) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws33A-0002H1-AC for emacs-orgmode@gnu.org; Wed, 04 Jun 2014 00:43:44 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ws338-0000CH-Ne for emacs-orgmode@gnu.org; Wed, 04 Jun 2014 06:43:43 +0200 Received: from 123.123.20.225 ([123.123.20.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jun 2014 06:43:42 +0200 Received: from eric by 123.123.20.225 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jun 2014 06:43:42 +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@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Daimrod writes: > Bastien writes: > >> Hi Eric, >> >> Eric Abrahamsen writes: >> >>> After Nicolas made the last round of improvements to the caching >>> mechanism I got far fewer hangs with Org, but they are still happening. >>> Maybe once a day or so, on average, editing something in an Org buffer >>> causes emacs to hang, and my fans to spin up, and there we are until I >>> kill emacs. [...] > By the way, if you want to see in which part the infloop occurs, you can > attach a gdb debugger to the running emacs, source the > /src/.gdbinit file and use the `xbacktrace' command. > > $ gdb > gdb) source /src/.gdbinit > ... > gdb) xbacktrace > > You can also use the `bt' command but it contains much more noise. I got another one just now (while moving from one org table cell to the next), and that was the gdb backtrace: "avl-tree--do-delete" (0xbfffe858) "avl-tree-delete" (0xbfffe998) "byte-code" (0xbfffeaa0) "byte-code" (0xbfffec30) "org-element--cache-process-request" (0xbfffedd8) "byte-code" (0xbfffeef0) "org-element--cache-sync" (0xbffff0a8) "org-element-at-point" (0xbffff1e8) "org-mode-flyspell-verify" (0xbffff338) "flyspell-word" (0xbffff478) "byte-code" (0xbffff580) "flyspell-post-command-hook" (0xbffff784) Not much, and probably not that useful. I'll start running org uncompiled, and try the debug-on-event trick. FWIW, this was the first lockup that *didn't* occur in a logbook drawer -- that's where I usually get them. Either a full lockup, or else the cache goes wonky so that adding log notes (or even just navigating in the drawer) gives me that "bound on wrong side of point" you get when you try to search forwards, backwards. E