From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: probable caching bug? Date: Fri, 06 Dec 2013 08:59:40 +0700 Message-ID: <874n6mbuyb.fsf@ericabrahamsen.net> References: <87pppcys45.fsf@ericabrahamsen.net> <87a9gfuwns.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VokgU-000135-B8 for emacs-orgmode@gnu.org; Thu, 05 Dec 2013 20:58:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VokgN-0001Xi-Tj for emacs-orgmode@gnu.org; Thu, 05 Dec 2013 20:58:26 -0500 Received: from plane.gmane.org ([80.91.229.3]:40428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VokgN-0001Xe-NB for emacs-orgmode@gnu.org; Thu, 05 Dec 2013 20:58:19 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VokgE-0000AZ-8x for emacs-orgmode@gnu.org; Fri, 06 Dec 2013 02:58:10 +0100 Received: from 223.204.248.94 ([223.204.248.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Dec 2013 02:58:10 +0100 Received: from eric by 223.204.248.94 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Dec 2013 02:58:10 +0100 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 Nicolas Goaziou writes: > Hello, > > Eric Abrahamsen writes: > >> While editing a plain list yesterday I noticed what I guess was a bug in >> the caching mechanism. > > It looks like it, indeed. > >> The list item was wrapped to several lines, and I noticed that calling >> C-e while on the last line gave me "wrong-type-argument >> integer-or-marker-p nil". Trying to fill the item with M-q gave me >> "user-error: An element cannot be parsed line 635". > > [...] > > Unfortunately, the source of the cache corruption may be totally > unrelated to the action triggering the error. Thus, cache bugs are quite > hard to reproduce. When hunting down one of them, I usually call the > following function after each non-trivial buffer modification. > > (defun ngz-random-test (&optional n contextp) > (save-excursion > (dotimes (k (or n 100)) > (goto-char (1+ (random (point-max)))) > (let ((real-element (let (org-element-use-cache) > (if contextp (org-element-context) > (org-element-at-point))))) > (or (equal real-element > (if contextp (org-element-context) (org-element-at-point))) > (message "`%s' at %d is corrupted." > (org-element-type real-element) > (org-element-property :begin real-element))))))) > > BTW, is your Org recent? I fixed a similar problem (i.e. cache > corruption in lists) about two weeks ago in commit > 4466af5c115b56377d7251e848860dc03212c583. Yes, it's up to date -- after I sent this message I started wondering if it had been a while since I updated, so I pulled and reloaded, and not long after that saw the bug again. I expect to see this again, so I can run the function above, but will reporting the results be of any use to you? If I know which element is corrupted, what should I be reporting back? E