Re: [O] [BUG] org-clock-sum cannot handle headings with more than 29 stars (was: Re: How to debug "org-clock-display: Args out of range: [48230 48230) 48230 38618 38618 0 0 0 0 0 ...], 61"

[Nick Dokos]

Gregor Zattler <address@hidden> wrote:

> Hi Nick, org developers,
> 
> while preparing a "minimal" example of my problem I finally
> realised that "61" was the deepest level of indentation of some
> inline tasks in my org file.  When I wrote them I only remembered
> inline tasks as with more than x stars and so I provided more
> than enough :-)
> 
> But this also applies to normal headings.  My Minimal org file to
> demonstrate the bug is now:
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> * dog
> ** dog
> *** dog
> **** dog
> ***** dog
> ****** dog
> ******* dog
> ******** dog
> ********* dog
> ********** dog
> *********** dog
> ************ dog
> ************* dog
> ************** dog
> *************** dog
> **************** dog
> ***************** dog
> ****************** dog
> ******************* dog
> ******************** dog
> ********************* dog
> ********************** dog
> *********************** dog
> ************************ dog
> ************************* dog
> ************************** dog
> *************************** dog
> **************************** dog
> ***************************** dog
> ****************************** ant
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> doing M-x org-clock-display (which in turn execs org-clock-sum)
> will fail.  It will not fail, with the last line removed.
> 
> I searched a bit in the sources (max.*level") but did not find
> documentation regarding the maximum number of stars in org
> files.  Perhaps it has to be documented or "lmax" raised in the sources.
> 
> Thanks for your help though, I first changed lmax as you proposed
> and it fixed the problem.
> 
> Ciao; gregor
> 
> * Nick Dokos <address@hidden> [12. Jan. 2012]:
> > Nick Dokos <address@hidden> wrote:
> >> Gregor Zattler <address@hidden> wrote:
> >>> Debugger entered--Lisp error: (args-out-of-range [49569 49569 49569 39957 
> >>> 3=
> >>> 9957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] 61)
> >>>   aref([49569 49569 49569 39957 39957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
> >>> 0=
> >>>  0 0 0 0 0 0] 61)
> >> 
> >> This tries to get the 61st element of a vector that has at most 30 or so
> >> elements, hence the complaint. But of course, that's hardly
> >> enlightening.  However, the backtrace shows that this code is inside the
> >> function org-clock-sum (in org-clock.el).  And if you look at that
> >> function, you see (where I have elided large swathes of code):
> >> 
> >>   (let* (...
> >>     (lmax 30)
> >>     (ltimes (make-vector lmax 0))
> >>     ...
> >> 
> >> So ltimes is a vector with *exactly* 30 elements. I would change that 30
> >> to 100 or so (something greater than 61 in any case) and retest. If that
> >> fixes it, then we know the culprit and then we can dedice which is the
> >> unreasonable one: the code or your subtree :-)
> > Or maybe that 61 is way off base. After all, there are only 5 non-trivial
> > entries in the vector.
> > 
> > The code that sets the level seems suspect to me:
> > 
> >       (let* ((headline-forced
> >               (get-text-property (point)
> >                                      :org-clock-force-headline-inclusion))
> >                  (headline-included
> >                   (or (null headline-filter)
> >                       (save-excursion
> >                         (save-match-data (funcall headline-filter))))))
> >         (setq level (- (match-end 1) (match-beginning 1)))
> > 
> > What do match-beginning/match-end return if headline-filter is nil?
> > The save-match-data is not done, so we get the results of whatever
> > random  search was done last before this code executed.
> 
> 

So I guess that despite my suspicions this code works (although I need
to understand how).  As for the failure, your example is of course
highly unlikely in the above form[fn:1], but much more likely in the
inline task case that bit you originally. But since expanding the vector
to 100 elements or so fixes the problem and seems to be both cheap and
expedient, I'd vote for that fix to go in and be done with it (perhaps
with a footnote in the clock section of the manual to identify the
limit).

Nick

Footnotes:

[fn:1] I doubt anybody uses > 30-level deep trees, although I would not be
       surprised to hear otherwise :-)