Re: Problem with printing plots

[Michael Goffioul]

On Fri, Mar 9, 2012 at 6:04 AM, Jordi Gutiérrez Hermoso
<address@hidden> wrote:
> On 9 March 2012 00:59, Daniel J Sebald <address@hidden> wrote:
>> On 03/08/2012 11:32 PM, Jordi Gutiérrez Hermoso wrote:
>>>
>>> 2012/3/9 Dmitri A. Sergatskov<address@hidden>:
>>>>
>>>> 2012/3/8 Jordi Gutiérrez Hermoso<address@hidden>:
>>>>
>>>>>    ../../run-octave -f -q -H -p
>>>>> /home/jordi/coding/vcs/octave-devel/doc/interpreter --eval
>>>>> "geometryimages ('voronoi', 'eps');"
>>>>>    error: get: A(I): index out of bounds; value 3 out of bound 2
>>>>
>>>>
>>>> I usually get this type of errors when I do (stupid) things like:
>>>>
>>>> octave:1>  sqrt=2
>>>> sqrt =  2
>>>> octave:2>  sqrt(4)
>>>> error: A(I): index out of bounds; value 4 out of bound 1
>>>
>>>
>>> Well, I'm baffled as to why I'm the only one seeing this problem. The
>>> only thing I can imagine could be causing it is my .octaverc, because
>>> jwe has also reported not seeing a problem, and I think he's also on
>>> Debian 6.0, so we should have the same version of all the important
>>> packages. But my .octaverc seems pretty innocuous:
>>>
>>>     edit mode async
>>>     edit home .
>>>     crash_dumps_octave_core(0);
>>>     PS1( "\\[\\033[01;36m\\]\\s:\\#>  \\[\\033[0m\\]" )
>>>     graphics_toolkit fltk;
>>>     warning("off", "Octave:broadcast");
>>>
>>> I can reproduce it quite reliably, reliably enough to use hg bisect on
>>> it and narrow it down to a mysterious-looking cset related to
>>> plotting. So I don't think I'm completely crazy about experiencing
>>> this problem while no one else does...
>>
>>
>> /home/jordi/coding/vcs/octave-devel/doc/interpreter --eval
>> "geometryimages ('voronoi', 'eps');"
>>    error: get: A(I): index out of bounds; value 3 out of bound 2
>>    error: called from:
>>    error:   /home/jordi/coding/vcs/octave-devel/scripts/plot/findobj.m
>> at line 205, column 9
>>    error: evaluating argument list element number 1
>>
>> It looks like a call to get(??, 'something') might be failing.  One way that
>> would fail is if the code is attempting to create a figure and fails so that
>> the figure is not in the array of "matryoshka pointers". Is there some type
>> of plot failing in the script?  Is there a hardcoded number in the script
>> expecting 3 to be valid, e.g., get(3, 'something')?  Just guessing.
>
> Okay, here is a clue. I just ran this in gdb. There is definitely a
> problem with this code. The reason I'm seeing this is that in my debug
> build I compiled with --enable-bounds-checking. On line 600 of
> src/graphics.cc, the p vector only has two coordinates but is being
> indexed one past the end.
>
> Ben, I think you understand this code best. Why is this indexing past the end?

The function convert_text_position assumes the given argument has 3 or
4 elements:
- 3 elements -> 3D text position
- 4 elements -> text extent rectangle

The patch Ben applied now uses convert_text_position on the position
property of the text object. When I wrote that code, the text position
was always a 3D vector. It seems it's not the case anymore, but that
part of the code hasn't been adapted.

Michael.