bugGNU Octave - Bugs: bug #39925, imagesc crash

 
 

bug #39925: imagesc crash

Submitted by:  Muhali <muhali>
Submitted on:  Tue 03 Sep 2013 09:47:54 AM UTC  
 
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 22 Oct 2013 09:18:50 PM UTC, comment #30:

Sorry. My comment below was meant for #40246.

Michael Godfrey <godfrey>
Tue 22 Oct 2013 09:06:36 PM UTC, 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>
Tue 22 Oct 2013 08:07:41 PM UTC, 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 22 Oct 2013 07:42:27 PM UTC, 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 22 Oct 2013 06:50:08 PM UTC, 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")
endif

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

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 22 Oct 2013 03:59:17 PM UTC, 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 22 Oct 2013 02:58:19 PM UTC, 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 22 Oct 2013 01:37:24 PM UTC, 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 20 Oct 2013 07:10:30 PM UTC, comment #22:

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

Rik <rik5>
Project Administrator
Sun 20 Oct 2013 04:19:02 PM UTC, 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 20 Oct 2013 03:32:33 PM UTC, 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 18 Oct 2013 03:58:22 PM UTC, 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 16 Oct 2013 03:58:09 PM UTC, 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 16 Oct 2013 03:50:36 PM UTC, 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 14 Oct 2013 03:20:15 PM UTC, 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 12 Oct 2013 03:16:34 PM UTC, 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 12 Oct 2013 02:29:48 PM UTC, 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 Member
Fri 11 Oct 2013 08:19:16 PM UTC, comment #13:

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

Doug Stewart <dastew>
Fri 11 Oct 2013 05:24:46 PM UTC, 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

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

and
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 11 Oct 2013 05:08:56 PM UTC, 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 11 Oct 2013 05:03:41 PM UTC, 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 11 Oct 2013 04:12:20 PM UTC, 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 11 Oct 2013 01:46:13 PM UTC, comment #8:

Ubuntu 10.04
hg id
cc9befe5d271 tip (10 days ago)

img = rand (2, 2);
graphics_toolkit ("fltk");
figure(1);
image ([1e9 2e9], [1 2], img);
figure(2);
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 06 Sep 2013 04:19:27 PM UTC, 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>
Fri 06 Sep 2013 03:11:22 PM UTC, 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 06 Sep 2013 01:40:59 PM UTC, 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 Member
Fri 06 Sep 2013 01:09:53 PM UTC, 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 Member
Fri 06 Sep 2013 12:46:25 PM UTC, 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 04 Sep 2013 10:10:40 PM UTC, 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 04 Sep 2013 01:24:37 AM UTC, 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 Member
Tue 03 Sep 2013 09:47:54 AM UTC, 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):
   
   
Comment:
   

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 22 Oct 2013 08:20:14 PM UTCrik5StatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Tue 22 Oct 2013 07:42:27 PM UTCrik5StatusConfirmed=>Ready For Test
    Fri 06 Sep 2013 01:09:53 PM UTCmtmillerItem GroupCrash=>Regression
    Wed 04 Sep 2013 01:24:37 AM UTCmtmillerStatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup