Re: Infinite recursion ?
Nick Dokos writes:
> David Masterson writes:
>
>> Haven't figured this out yet, but I seem to be hitting an "infinite
>> recursion" bug that eventually dies when it runs out of memory.
>>
>> The scenario (so far) is trying to change an Org tag in the agenda
>> (':'). The command gives me the tags that I then edit and save whereupon
>> it sits in an infinite recursion until it hits a limit in Emacs. If I
>> quit, the files seem to have been updated, but the Agenda isn't. I'm
>> still trying to figure out how to debug this. Setting debug-on-quit was
>> not consistent and didn't seem to have a large list of function calls
>> (ie. the recursion). Any ideas?
>>
>> This is Emacs 26.3 with Orgmode 9.4. I'm also using Org-Super-Agenda
>> from Melpa (20200310.1337).
>>
>> Side question that might be related: org-agenda started positioning
>> itself at the end of the agenda rather than the beginning after building
>> the agenda. I don't think I changed something for this. What could
>> cause this?
>
> What's the error message? Did you try setting `debug-on-eror'? Does that give
> a more useful backtrace?
The error has to do with org-agenda-property-list. I'm going to file
this as a bug.
--
David Masterson
Re: Infinite recursion ?
Nick Dokos writes: > What's the error message? Did you try setting `debug-on-eror'? Does that give > a more useful backtrace? Backtrace: no variable named `debug-on-eror' - maybe you made an eror :-) Sigh - should be `debug-on-error'. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: Infinite recursion ?
David Masterson writes:
> Haven't figured this out yet, but I seem to be hitting an "infinite
> recursion" bug that eventually dies when it runs out of memory.
>
> The scenario (so far) is trying to change an Org tag in the agenda
> (':'). The command gives me the tags that I then edit and save whereupon
> it sits in an infinite recursion until it hits a limit in Emacs. If I
> quit, the files seem to have been updated, but the Agenda isn't. I'm
> still trying to figure out how to debug this. Setting debug-on-quit was
> not consistent and didn't seem to have a large list of function calls
> (ie. the recursion). Any ideas?
>
> This is Emacs 26.3 with Orgmode 9.4. I'm also using Org-Super-Agenda
> from Melpa (20200310.1337).
>
> Side question that might be related: org-agenda started positioning
> itself at the end of the agenda rather than the beginning after building
> the agenda. I don't think I changed something for this. What could
> cause this?
What's the error message? Did you try setting `debug-on-eror'? Does that give
a more useful backtrace?
--
Nick
"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: Infinite recursion ?
Set debug-on-quit so you can see, by hitting C-g, where the system is stuck. That may help identify the problem and would, in any case, be useful in a bug report. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-18-gaea110
Re: Infinite recursion ?
David Masterson writes:
> Haven't figured this out yet, but I seem to be hitting an "infinite
> recursion" bug that eventually dies when it runs out of memory.
>
> The scenario (so far) is trying to change an Org tag in the agenda
> (':'). The command gives me the tags that I then edit and save whereupon
> it sits in an infinite recursion until it hits a limit in Emacs. If I
> quit, the files seem to have been updated, but the Agenda isn't. I'm
> still trying to figure out how to debug this. Setting debug-on-quit was
> not consistent and didn't seem to have a large list of function calls
> (ie. the recursion). Any ideas?
>
> This is Emacs 26.3 with Orgmode 9.4. I'm also using Org-Super-Agenda
> from Melpa (20200310.1337).
I think that this problem has something to do with
org-agenda-property-list. When I turned that on for a property, I
began to have problems using the agenda edit commands (for instance ":")
where it would have trouble redrawing the agenda. When I turned this
off, things started working better,
Should I file a bug?
> Side question that might be related: org-agenda started positioning
> itself at the end of the agenda rather than the beginning after building
> the agenda. I don't think I changed something for this. What could
> cause this?
This is still happening.
--
David Masterson
Re: infinite recursion org-update-id-locations / org-entry-properties / org-entry-blocked-p / org-edna / org-id-find / org-id-update-locations
I just tried using straight for org, and master (a1e5bee5c) has a rewritten org-update-id-locations that uses regexps to find the IDs. It appears to have fixed the problem (for cases that I tried). -Justin On 7/30/20 4:21 PM, Justin Vallon wrote: > I copy by org files between 2 machines. Thus, my .org-id-locations file > gets stale when I archive on one machine, then sync the org files. > > I also use org-edna. > > Sometimes, org-agenda will go into an infinite loop (recursion depth, > etc) when scanning. > > I believe what is happening is: > > - org-agenda / org-edna builds the agenda, and hits a "missing" id(X) > - org-update-id-locations starts scanning files/nodes to refresh > - org-cached-entry-get tries to get all properties > - org-entry-blocked-p is called > - org-edna then tries to parse the BLOCKER property > - the property mentions "id(Y)", which has not been found (yet) > - cache miss, rescan files > > The X and Y could be different, but once id(Y) is missing and the > cache-miss happens during id-scanning, it will repeat. > > I suppose it also might be sensitive to the order of files in the list, > since scanning the archive first would scan the older IDs, then the > active file would reference those older IDs. However, I would imagine > there would be trouble if an "earlier" node in the active file > referenced an ID that appeared "later" in the file, since the file is > being scanned in-order. > > I haven't tried this, but the simplest case to reproduce might be to > delete the .org-id-locations file, then feed it: > > * Second > BLOCKER: id(first) > * First > ID: first > > I can try to build a (simple) reproducible test case if this is unclear. > > My work-around is to disable org-edna, run org-id-update-id-locations, > then reenable org-edna. > -- -Justin justinval...@gmail.com
