[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"

[Gregor Zattler <telegraph@gmx.net>]

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 <nicholas.dokos@hp.com> [12. Jan. 2012]:
> Nick Dokos <nicholas.dokos@hp.com> wrote:
>> Gregor Zattler <telegraph@gmx.net> 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.