From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daimrod Subject: Re: still seeing semi-regular lockups Date: Thu, 05 Jun 2014 13:29:27 +0900 Message-ID: <874n00ges8.fsf@tanger.home> References: <87siocrbyb.fsf@ericabrahamsen.net> <87siobtn1i.fsf@bzg.ath.cx> <87ha4r1j91.fsf@tanger.home> <87r435wab6.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsPO3-0001da-Ke for emacs-orgmode@gnu.org; Thu, 05 Jun 2014 00:34:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsPNy-0002YG-Tb for emacs-orgmode@gnu.org; Thu, 05 Jun 2014 00:34:47 -0400 Received: from mail-pd0-x22d.google.com ([2607:f8b0:400e:c02::22d]:63527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsPIz-0000hK-GC for emacs-orgmode@gnu.org; Thu, 05 Jun 2014 00:29:33 -0400 Received: by mail-pd0-f173.google.com with SMTP id v10so505912pde.4 for ; Wed, 04 Jun 2014 21:29:32 -0700 (PDT) In-Reply-To: <87r435wab6.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Wed, 04 Jun 2014 12:47:09 +0800") 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: Eric Abrahamsen Cc: emacs-orgmode@gnu.org Eric Abrahamsen writes: > 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) It seems the lockup also happens in `org-element--cache-...'. > Not much, and probably not that useful. I'll start running org > uncompiled, and try the debug-on-event trick. Thanks for you time! > 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. That's weird (in my cases it usually mess up with the input-method). -- Daimrod/Greg