bugGNU Octave - Bugs: bug #39925, imagesc crash

 
 

bug #39925: imagesc crash

Submitter:  Muhali <muhali>
Submitted:  Tue 03 Sep 2013 09:47:54 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group Member
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>
Group Member
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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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 += (xmin - im_xmin)/nor_dx + 1;


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>
Group 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:


image (1e3  + [1 2], [1 2], rand (2));
image (1e12 + [1 2], [1 2], rand (2));


Mike Miller <mtmiller>
Group 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


imagesc(1e9+[1 2], [1 2], rand(2,2))
imagesc(1e10+[1 2], [1 2], rand(2,2))


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


parent: 17630:484c9a6f4f27 tip
 maint: Fix compiler shadowed variable warning in curl_transfer constructor.
branch: default


Rik <rik5>
Group 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>
Group Member
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>
Group 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:


stopped in /home/mike/src/octave/default/build-default/../scripts/image/image.m at line 159
159:   set (hax, "xlim", xlim, "ylim", ylim);
debug> xlim
xlim =

   1.00000000005000e+10   1.00000000025000e+10

debug> ylim
ylim =

   0.500000000000000   2.500000000000000

debug> dbstep


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

Mike Miller <mtmiller>
Group 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:


octave:1> img = rand (2, 2);
octave:2> graphics_toolkit ("fltk");
octave:3> image ([1e9 2e9], [1 2], img);
octave:4> image ([1e10 2e10], [1 2], img);


but this crashes:


octave:5> image ([1e9 1e9], [1 2], img);
octave:6> image ([1e10 1e10], [1 2], img);


And here is a backtrace:


#0  opengl_renderer::draw_image (this=0xd24350, props=...) at ../../libinterp/corefcn/gl-render.cc:2598
#1  0x00007ffff695df63 in opengl_renderer::draw (this=0xd24350, go=..., toplevel=true) at ../../libinterp/corefcn/gl-render.cc:573
#2  0x00007ffff6964793 in opengl_renderer::draw_axes_children (this=this@entry=0xd24350, props=...) at ../../libinterp/corefcn/gl-render.cc:1371
#3  0x00007ffff6964d78 in opengl_renderer::draw_axes (this=0xd24350, props=...) at ../../libinterp/corefcn/gl-render.cc:1426
#4  0x00007ffff695df63 in opengl_renderer::draw (this=0xd24350, go=..., toplevel=false) at ../../libinterp/corefcn/gl-render.cc:573
#5  0x00007ffff6970f3b in opengl_renderer::draw (this=this@entry=0xd24350, hlist=..., toplevel=toplevel@entry=false) at ../../libinterp/corefcn/gl-render.h:73
#6  0x00007ffff6963fc2 in opengl_renderer::draw_figure (this=0xd24350, props=...) at ../../libinterp/corefcn/gl-render.cc:599
#7  0x00007ffff695df63 in opengl_renderer::draw (this=this@entry=0xd24350, go=..., toplevel=toplevel@entry=true) at ../../libinterp/corefcn/gl-render.cc:573
#8  0x00007fffe6b314e8 in OpenGL_fltk::draw (this=0xd24230) at ../../libinterp/dldfcn/__init_fltk__.cc:193
#9  0x00007fffe68f629d in Fl_Gl_Window::flush (this=0xd24230) at Fl_Gl_Window.cxx:388
#10 0x00007fffe65ecd72 in flush (this=<optimized out>) at ../FL/x.H:160
#11 Fl::flush () at Fl.cxx:741
#12 0x00007fffe65edd90 in Fl::wait (time_to_wait=<optimized out>, time_to_wait@entry=0) at Fl.cxx:507
#13 0x00007fffe65eddad in Fl::check () at Fl.cxx:619
#14 0x00007fffe6b1fce6 in __fltk_redraw__ () at ../../libinterp/dldfcn/__init_fltk__.cc:1860
#15 0x00007fffe6b3114b in fltk_graphics_toolkit::redraw_figure (this=<optimized out>, go=...) at ../../libinterp/dldfcn/__init_fltk__.cc:1983
#16 0x00007ffff6a1e017 in redraw_figure (go=..., this=0x7fffffffb880) at corefcn/graphics.h:2257
#17 Fdrawnow (args=...) at ../../libinterp/corefcn/graphics.cc:9642


Mike Miller <mtmiller>
Group 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>
Group 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>
Group Member
Tue 03 Sep 2013 09:47:54 AM UTC, original submission:  

running these two commands interactively, using fltk


imagesc(1e9+[1 2], [1 2], rand(2,2))
imagesc(1e10+[1 2], [1 2], rand(2,2))


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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-22 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2013-10-22 rik5 StatusConfirmed Ready For Test
    2013-09-06 mtmiller Item GroupSegfault, Bus Error, etc. Regression
    2013-09-04 mtmiller StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code