* probable caching bug?
@ 2013-12-05 2:00 Eric Abrahamsen
2013-12-05 15:47 ` Nicolas Goaziou
0 siblings, 1 reply; 6+ messages in thread
From: Eric Abrahamsen @ 2013-12-05 2:00 UTC (permalink / raw)
To: emacs-orgmode
While editing a plain list yesterday I noticed what I guess was a bug in
the caching mechanism.
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".
I found that adding another item with M-RET allowed me to go back up to
the previous item and fill it successfully. Later on, though, the same
error cropped up with other items, and I wasn't always able to bang it
back into shape. I was right in the middle of something and didn't have
time for extensive debugging, but here's the text I was on, and the
traceback for the wrong type argument below that:
****** Selected Quotes
- Illness is a subtle negotiation [微调] between life and death. Like
a never-ending course in philosophy, it has taught me some of the
meaning of life, and of death.
- One can only save the drowning when oneself is on the shore.
- Night was falling. Carrying his large leather suitcase, Zhuang
Zhidie arrived alone at the train station. After queuing for his ticket, <--- line 365
Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
org-element-item-parser(27819 ((27512 0 "- " nil nil nil 27681) (27681 0 "- " nil nil nil 27744) (27744 0 "- " nil nil nil 27819)) t)
org-element--current-element(27819 element item ((27512 0 "- " nil nil nil 27681) (27681 0 "- " nil nil nil 27744) (27744 0 "- " nil nil nil 27819)))
byte-code("BYTE CODE HERE" [element special-flag type pos org-element-use-cache org-element--cache (item table-row) (plain-list table) 0 org-element--cache-sync gethash eql objects org-element--current-element derived-mode-p org-mode nil org-element-cache-reset puthash :parent org-add-props plist-put plain-text (item plain-list) :structure :end get-text-property plist-get throw exit :contents-begin :contents-end (plain-list table) (center-block drawer dynamic-block inlinetask property-drawer quote-block special-block) (item plain-list) plain-list item property-drawer node-property table table-row org-element--cache-status data cached end struct parent value property elem-end ...] 6)
org-element-at-point()
org-end-of-line(nil)
call-interactively(org-end-of-line nil nil)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: probable caching bug?
2013-12-05 2:00 probable caching bug? Eric Abrahamsen
@ 2013-12-05 15:47 ` Nicolas Goaziou
2013-12-06 1:59 ` Eric Abrahamsen
0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Goaziou @ 2013-12-05 15:47 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: emacs-orgmode
Hello,
Eric Abrahamsen <eric@ericabrahamsen.net> 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.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: probable caching bug?
2013-12-05 15:47 ` Nicolas Goaziou
@ 2013-12-06 1:59 ` Eric Abrahamsen
2013-12-06 15:30 ` Nicolas Goaziou
0 siblings, 1 reply; 6+ messages in thread
From: Eric Abrahamsen @ 2013-12-06 1:59 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: probable caching bug?
2013-12-06 1:59 ` Eric Abrahamsen
@ 2013-12-06 15:30 ` Nicolas Goaziou
2013-12-07 1:58 ` Eric Abrahamsen
0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Goaziou @ 2013-12-06 15:30 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: emacs-orgmode
Hello,
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> 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.
Well, too bad.
> 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?
The corrupted element is only interesting when there's a pattern (e.g.
only lists and items are corrupted). Another important information is
the action triggering the corruption. The function helps to find it out.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: probable caching bug?
2013-12-06 15:30 ` Nicolas Goaziou
@ 2013-12-07 1:58 ` Eric Abrahamsen
2013-12-07 9:19 ` Nicolas Goaziou
0 siblings, 1 reply; 6+ messages in thread
From: Eric Abrahamsen @ 2013-12-07 1:58 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> 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.
>
> Well, too bad.
>
>> 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?
>
> The corrupted element is only interesting when there's a pattern (e.g.
> only lists and items are corrupted). Another important information is
> the action triggering the corruption. The function helps to find it out.
Ah, so you use it in after-change-functions?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: probable caching bug?
2013-12-07 1:58 ` Eric Abrahamsen
@ 2013-12-07 9:19 ` Nicolas Goaziou
0 siblings, 0 replies; 6+ messages in thread
From: Nicolas Goaziou @ 2013-12-07 9:19 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: emacs-orgmode
Hello,
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>> The corrupted element is only interesting when there's a pattern (e.g.
>> only lists and items are corrupted). Another important information is
>> the action triggering the corruption. The function helps to find it out.
>
> Ah, so you use it in after-change-functions?
I call it manually, but that's the idea, yes.
If you want to add the function to `after-change-functions', you will
need to change its signature (i.e. add three dummy arguments).
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-12-07 9:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-05 2:00 probable caching bug? Eric Abrahamsen
2013-12-05 15:47 ` Nicolas Goaziou
2013-12-06 1:59 ` Eric Abrahamsen
2013-12-06 15:30 ` Nicolas Goaziou
2013-12-07 1:58 ` Eric Abrahamsen
2013-12-07 9:19 ` Nicolas Goaziou
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).