[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with printing plots
From: |
Michael Goffioul |
Subject: |
Re: Problem with printing plots |
Date: |
Fri, 9 Mar 2012 09:33:36 +0000 |
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.
- Re: Problem with printing plots, (continued)
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots, Ben Abbott, 2012/03/09
- Re: Problem with printing plots, Michael Goffioul, 2012/03/10
- Re: Problem with printing plots, Ben Abbott, 2012/03/10
- Re: Problem with printing plots, Michael Goffioul, 2012/03/10
- Re: Problem with printing plots, Ben Abbott, 2012/03/10
- Re: Problem with printing plots, Michael Goffioul, 2012/03/10
- Re: Problem with printing plots, Ben Abbott, 2012/03/10
- Re: Problem with printing plots, logari81, 2012/03/12
- Re: Problem with printing plots, Jordi Gutiérrez Hermoso, 2012/03/10
- Re: Problem with printing plots,
Michael Goffioul <=