bugGNU Octave - Bugs: bug #39925, imagesc crash


bug #39925: imagesc crash

Submitted by:  Muhali <muhali>
Submitted on:  Tue Sep 3 09:47:54 2013  
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Tue Oct 22 21:18:50 2013, comment #30:

Sorry. My comment below was meant for #40246.

Michael Godfrey <godfrey>
Project Member
Tue Oct 22 21:06:36 2013, comment #29:

Not quite fine. The warning message repeats
every time thew mouse moves over the plot.
This is observed by:
plot (1:200)
plot([0 10^44])

then move mouse over the plot.

A choice:
1. Fix the redraw on mouse movement.
2. Fix the warning to only happen once.

It could be as hard to do 1. as 2. !!

Michael Godfrey <godfrey>
Project Member
Tue Oct 22 20:07:41 2013, comment #28:

I tried your code and it works fine for me.
You should push it.
This does not fix the single precision problem for fltk.
But it does stop the crashing and out of memory messages.

Doug Stewart <dastew>
Tue Oct 22 19:42:27 2013, comment #27:

The problem with tackling it in the m-file is that someone can go ahead and change the xdata or ydata range using the set() command. I think the check needs to be downstream in gl-render.cc. Most of the code in graphics.cc is general and applies to either the fltk or gnuplot backend. Thus, it shouldn't care that values are floats or not. I checked in a changeset here (http://hg.savannah.gnu.org/hgweb/octave/rev/36d646ead233) which seems to solve the problem. When I used gdb to step through the code I realized that we were exceeding the precision range which meant that diff (x) was coming out 0 and then divisions by 0 were causing all sorts of problems. Can you verify that things work with the new changeset. If so, I think we can finally close this bug.

Rik <rik5>
Project Administrator
Tue Oct 22 18:50:08 2013, comment #26:

Here is a simple check on the x and y ranges that catches the situation before it becomes a problem (crash)

in file image.m at line 148 insert this code:

if (diff (x) < 2*eps)
error( "ERROR ---> X range is too small")

if (diff (y) < 2*eps)
error( "ERROR ---> Y range is too small")

If this is an acceptable solution then I can make a hg change set.
Should that by just eps or 2*eps?

Doug Stewart <dastew>
Tue Oct 22 15:59:17 2013, comment #25:

I don't understand the difference either. However, I wonder if we couldn't "kill two bugs with one stone" as it were. The problem now seews to be that we have reached the limits of single precision. There is already a second bug report that is a blocker for the 3.8 release which is to implement a detection of float overflow and issue an error rather than continue plotting (bug #40246). I wonder if we solved that one first whether this one would never be reached?

Rik <rik5>
Project Administrator
Tue Oct 22 14:58:19 2013, comment #24:

I see now that 1e17 + 1 =1e17 we have reached the limit of our precision.

So the original problem at 1e10 has disappeared

Now what I see is that if we do 1e17 for the x axes then it crashes but if we do 1e17 for the y axes then we get an out of memory error.

Why the difference????

Doug Stewart <dastew>
Tue Oct 22 13:37:24 2013, comment #23:

I have interesting results.
Originally the problem was when we went from 1e9 to 1e10 or larger.
Now (after some recent changes the problem only shows up when we go from 1e16 to 1e17 or larger
I will try again today to track this down.

Doug Stewart <dastew>
Sun Oct 20 19:10:30 2013, comment #22:

Alas, you're right. This is still a problem with the example you posted.

Rik <rik5>
Project Administrator
Sun Oct 20 16:19:02 2013, comment #21:

I still see the same crash with a new build
octave:1> image (1e7 + [1 2], 1 + [1 2], rand (2));
octave:2> image (1e17 + [1 2], 1 + [1 2], rand (2));
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault (core dumped)
doug@doug-desktopq4:~/octavec1/octaves1/build1$ hg id
4d8ddc44d1f2 tip

Doug Stewart <dastew>
Sun Oct 20 15:32:33 2013, comment #20:

Some changes have been made to the image and imagesc m-files and I am no longer able to get a segfault using the original reporter's code. If someone else can verify this I think we can close this report. Testing was done with cset 17703:4d8ddc44d1f2.

Rik <rik5>
Project Administrator
Fri Oct 18 15:58:22 2013, comment #19:

I am working with gdb to try and figure out what is the problem.
No answer yet but I will keep at it.

Doug Stewart <dastew>
Wed Oct 16 15:58:09 2013, comment #18:

I'm pretty sure the value of nor_dx was 1 which meant that xmin which was 1e10 overflowed the int variable j0.

Rik <rik5>
Project Administrator
Wed Oct 16 15:50:36 2013, comment #17:

Rik said:
"The proximate cause is line 2603 of gl-render.cc:
j0 += (xmin - im_xmin)/nor_dx + 1;

What value did nor_dx have????

Doug Stewart <dastew>
Mon Oct 14 15:20:15 2013, comment #16:

The proximate cause is line 2603 of gl-render.cc:

j0 is an integer and this calculation overflows producing a negative value for j0. Later, j0 is used as an index into an array which causes the segfault.

I still don't understand the root cause though. It seems it shouldn't be possible to reach here with the values of xmin and im_xmin.

Rik <rik5>
Project Administrator
Sat Oct 12 15:16:34 2013, comment #15:

I also played with the Y axis the same as we are doing to the X axis.
I cannot make it crash with the Y axis, but I did get an out of memory error message, when playing with both X and Y axis at the same time.

So one guess is that it is some kind of out of memory that crashes instead of giving an out of memory error message. Just a guess at this point.

Doug Stewart <dastew>
Sat Oct 12 14:29:48 2013, comment #14:

Doug, thanks for testing all of these combinations. Your results seem consistent with what I found earlier, that the two image calls have to be on the same figure and in the order specified, from some range <= 1e9 to some range >= 1e10 (or some threshold in between those 2).

So for example, this also crashes in the same way:

Mike Miller <mtmiller>
Project Administrator
Fri Oct 11 20:19:16 2013, comment #13:

imagesc(1e30+[1 2], [1 2], rand(2,2))
imagesc(1e30+[1 2], [1 2], rand(2,2)) -does not crash

Doug Stewart <dastew>
Fri Oct 11 17:24:46 2013, comment #12:

More info on this problem:

The first call can have any power and still work.
The second call will only work if it is 1e9 or less.
imagesc(1e20+[1 2], [1 2], rand(2,2)) -works by itself
imagesc(1e30+[1 2], [1 2], rand(2,2)) -works by itself

imagesc(1e30+[1 2], [1 2], rand(2,2))
imagesc(1e20+[1 2], [1 2], rand(2,2)) -crash
imagesc(1e9+[1 2], [1 2], rand(2,2))
imagesc(1e30+[1 2], [1 2], rand(2,2)) -crash

imagesc(1e30+[1 2], [1 2], rand(2,2))
imagesc(1e9+[1 2], [1 2], rand(2,2)) - no crash

so it seems that if the second call is with a number greater than 1e9 then it crashes.

Doug Stewart <dastew>
Fri Oct 11 17:08:56 2013, comment #11:

But I do not get a crash if I reverse the order!!!
imagesc(1e10+[1 2], [1 2], rand(2,2))
imagesc(1e9+[1 2], [1 2], rand(2,2))

This works!!!?????

Doug Stewart <dastew>
Fri Oct 11 17:03:41 2013, comment #10:

Yes I still get a crash with:
imagesc(1e9+[1 2], [1 2], rand(2,2))
imagesc(1e10+[1 2], [1 2], rand(2,2))

Doug Stewart <dastew>
Fri Oct 11 16:12:20 2013, comment #9:

What about the original reporter's code?

I ran

and it still segfaults. This is with a tip from today (10/11/13)

Rik <rik5>
Project Administrator
Fri Oct 11 13:46:13 2013, comment #8:

Ubuntu 10.04
hg id
cc9befe5d271 tip (10 days ago)

img = rand (2, 2);
graphics_toolkit ("fltk");
image ([1e9 2e9], [1 2], img);
image ([1e10 1e10], [1 2], img)

There was no crash. Both figures looked the same except for the numbers on the X axis.

This works for me!!!

Doug Stewart <dastew>
Fri Sep 6 16:19:27 2013, comment #7:

My comment #15 in (https://savannah.gnu.org/bugs/?func=detailitem&item_id=32980) is, I think, a way to fix the general problem.
Something like this must have been done in other packages
which make use of OpenGL.

Michael Godfrey <godfrey>
Project Member
Fri Sep 6 15:11:22 2013, comment #6:

Just a guess, this problem is likely due to the fact that OpenGL uses floats (single) for the backend. This has caused no end of trouble in the past (https://savannah.gnu.org/bugs/?func=detailitem&item_id=32980) and is one of the things preventing Octave from leaving gnuplot behind.

Rik <rik5>
Project Administrator
Fri Sep 6 13:40:59 2013, comment #5:

One further detail. The crash occurs when the xlim and ylim properties are set on line 159 of image.m:

and segfault. Hopefully this helps someone pinpoint the problem in the graphics library.

Mike Miller <mtmiller>
Project Administrator
Fri Sep 6 13:09:53 2013, comment #4:

Marking as regression.

It doesn't matter whether image or imagesc is called. It has to do with the x-axis limits as they are specified. This works:

but this crashes:

And here is a backtrace:

Mike Miller <mtmiller>
Project Administrator
Fri Sep 6 12:46:25 2013, comment #3:

> Muhali, could you use 'hg bisect' to track down which changeset created the problem?

I would if I could. Sorry.

Muhali <muhali>
Wed Sep 4 22:10:40 2013, comment #2:

This is likely something that has been introduced recently with Carne's work on the image commands. I just checked and it doesn't occur in 3.6.4 so this is a regression.

Muhali, could you use 'hg bisect' to track down which changeset created the problem?

Rik <rik5>
Project Administrator
Wed Sep 4 01:24:37 2013, comment #1:

Confirmed here as well, each command on its own does not crash, and the plot has to remain open.

Mike Miller <mtmiller>
Project Administrator
Tue Sep 3 09:47:54 2013, original submission:

running these two commands interactively, using fltk

crashes my octave (built today).

Program received signal SIGSEGV, Segmentation fault.
opengl_renderer::draw_image (this=0xe153d0, props=...) at corefcn/gl-render.cc:2598
2598 a[idx+2] = xcdata(i,j,2);

Muhali <muhali>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by dastew (Posted a comment)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by muhali (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue Oct 22 20:20:14 2013rik5StatusReady For Test=>Fixed
    Tue Oct 22 19:42:27 2013rik5StatusConfirmed=>Ready For Test
    Fri Sep 6 13:09:53 2013mtmillerItem GroupSegfault, Bus Error, etc.=>Regression
    Wed Sep 4 01:24:37 2013mtmillerStatusNone=>Confirmed

    Back to the top

    Powered by Savane 3.1-cleanup1