bugGNU Octave - Bugs: bug #35292, FLTK plot figure crashes when...

 
 

bug #35292: FLTK plot figure crashes when using right-mouse zoom and logarithmic axes

Submitter:  John <jjo>
Submitted:  Wed 11 Jan 2012 08:14:53 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 04 Feb 2012 03:32:27 PM UTC, comment #32: 

OK, I checked in one additional change on the stable branch:

http://hg.savannah.gnu.org/hgweb/octave/rev/a646cee995cf

With this change, zooming should work for positive log scale axes with the mouse wheel or the zoom box, but it should be disabled for any negative log scale axis.

John W. Eaton <jwe>
Group administrator
Sat 04 Feb 2012 12:24:51 PM UTC, comment #31: 

I found that zooming foe negative logs is disabled for the mouse wheel but not for the right mouse box.

Using the right mouse button (button 3) zoom still works but all the values change to positive values.

Doug Stewart <dastew>
Sat 04 Feb 2012 02:41:46 AM UTC, comment #30: 

I verified that the pixel positions seem to be correct now in linear, log, and negative log plots. 

In fact, FLTK does a better job now than gnuplot.  On gnuplot, plots with negative log axes are still shown as positive.  The absolute value of the coordinate is correct, but they apparently forgot to take care of the minus sign.

I will close this bug and all the others related to mouse coordinates.

Rik <rik5>
Group administrator
Sat 04 Feb 2012 01:03:43 AM UTC, comment #29: 

I checked in a few more changes:

First, on the stable branch, I fixed a problem with minor tick marks for log scale plots, then disabled zooming for logscale axes.  I disabled it because I don't see a way to make this work without some interface changes that could break binary compatibility.  Maybe I went too far with that though.  Perhaps it could be made to work with positive values but not negative?

http://hg.savannah.gnu.org/hgweb/octave/rev/a9a42d630bd5
http://hg.savannah.gnu.org/hgweb/octave/rev/45f5a5d5656f

Next, I fixed (I think) the pixel position to graph coordinate transformation for log scale plots with negative values.

http://hg.savannah.gnu.org/hgweb/octave/rev/5a2b012b10c7

So I think the zooming and panning problems are finally fixed on the default branch.  Can someone verify?

Also, it appears to me that the cursor is now showing the correct values for plot coordinates in linear, log, and negative log plots.  If all those things appear to be working, I think we can close this report.

John W. Eaton <jwe>
Group administrator
Fri 03 Feb 2012 02:31:11 AM UTC, comment #28: 

val = std::log10 (-val); this is line 6578
i changed it to
val = std::log10 (val); this is line 6578
Now the mouse weel zoom works OK but
the zoom box with the right mouse button
changes the negative values of the y axis to positive when zooming.
:-)
I will keep looking


Doug Stewart <dastew>
Fri 03 Feb 2012 02:05:48 AM UTC, comment #27: 

 I think I found the nan problem  on line 6578 of graphics.cc
if (is_logscale)
    {
      if (is_negative)
        {
          double tmp = hi;
          hi = std::log10 (-lo);
          lo = std::log10 (-tmp);
          val = std::log10 (-val);    this is line 6578
        }
  
val is pos when we get here and this makes nans
I will recompile and try my fix

Doug Stewart <dastew>
Thu 02 Feb 2012 10:14:04 PM UTC, comment #26: 

Hmm, zooming or panning for loglog with negative values doesn't work at all for me.

For example:


x = y = -(3:5); loglog (x, y);


I'm pretty sure the problem is with the conversion from pixel position to graph coordinate.

Look at the coordinate value that is displayed when you move the mouse around.  For me, it is not negative, and not the value corresponding to points on the plot.  Is it a log value?  It doesn't match what I would expect, but I know there is another bug with coordinate values.

In any case, the code in do_zoom code expects VAL to be the position of the mouse pointer in axes coordinate values.  Fix that, and I think zooming will work correctly.

I don't understand the coordinate transformation code.  Maybe Michael Goffioul can help with this problem?

John W. Eaton <jwe>
Group administrator
Thu 02 Feb 2012 08:40:25 PM UTC, comment #25: 

Rik is correct I am at

doug@doug-desktop:~/octavecompile/octave$ hg id
17de694961f5


Doug Stewart <dastew>
Thu 02 Feb 2012 08:36:52 PM UTC, comment #24: 

Doug,

Are you sure you are at the tip?  'hg tip' reports what the tip of the repository is, but that is not the same as where your local directory is.  Try 'hg id' to identify the current revision of your directory.

I am at revision 14317 on the stable branch and I can zoom correctly.  This is on an Ubuntu Linux system.

Rik <rik5>
Group administrator
Thu 02 Feb 2012 08:04:06 PM UTC, comment #23: 

using

octave$ hg tip
changeset:   14317:7dee2bb231c1
branch:      stable

this
graphics_toolkit fltk;
a = logspace (-5, 1, 10);
b =-logspace (-5, 1, 10);
loglog (a, b);
## Now try to pan the plot and it goes blank and the axis gets set to NaN.

also gives nans and blank screen  when zooming

Doug Stewart <dastew>
Thu 02 Feb 2012 06:18:20 PM UTC, comment #22: 

Zooming and panning now work with log axes on the development branch.

There is one exception.  If you create a loglog plot with negative values and attempt panning, before zooming, then the plot goes blank.  If you zoom first, which must initialize some values, then the plot behaves correctly.


graphics_toolkit fltk;
a = logspace (-5, 1, 10);
b =-logspace (-5, 1, 10);
loglog (a, b);
## Now try to pan the plot and it goes blank and the axis gets set to NaN.


I'm in the process of closing down the other duplicate bugs for this behavior.

Rik <rik5>
Group administrator
Thu 02 Feb 2012 05:15:49 PM UTC, comment #21: 

I checked in some changes:

stable branch:

http://hg.savannah.gnu.org/hgweb/octave/rev/d4f37aa5d126
http://hg.savannah.gnu.org/hgweb/octave/rev/1734c3a48f31

followed by a merge from stable to default, then the following change on the default branch:

http://hg.savannah.gnu.org/hgweb/octave/rev/17de694961f5

Could someone please verify that these solve the reported problems in this and other related bug reports and if so, close the reports?

John W. Eaton <jwe>
Group administrator
Thu 02 Feb 2012 04:16:51 PM UTC, comment #20: 

The patch works good for me.
Zooming with mouse wheel is OK.
Zooming with right mouse button is OK.
Panning is OK.

Doug Stewart <dastew>
Thu 02 Feb 2012 05:03:33 AM UTC, comment #19: 

The attached patch seems to fix the problem for me for both zooming and panning, but I haven't done a lot of testing.

Unfortunately, it requires a change to a signature of a public function to fix the panning problem, so I don't think that portion of the fix can be included in 3.6.1.  But if this fix is OK, then we could use the zooming part of the fix and simply disable panning for logscale to avoid the error.

Then this problem could be fully fixed in the next major release.

There may be another similar problem for rotation.  I haven't checked that.

(file #24954)

John W. Eaton <jwe>
Group administrator
Thu 02 Feb 2012 03:12:51 AM UTC, comment #18: 

in graphics.cc in the area of line 5949 we have

if (is_logscale && ! (xisinf (hi) || xisinf (lo)))
    {
      // FIXME - what if (hi-lo) < tick_sep?
      //         ex: loglog ([1 1.1])
      tick_sep = std::max (tick_sep, 1.);
      tick_sep = std::ceil (tick_sep);
    }
farther down we have:
 Matrix tmp_mticks (1, n * (tmp_ticks.numel () - 1));
when it crashes tmp_ticks.numel ()  is zero
and therefore it tries to make an array with dim (1,-7).

It seem to be when the x range is less than 1 log cycle
so the fixme  likely needs fixing.

I will look at it more, but just wanted to document where the problem is.

Doug Stewart <dastew>
Tue 24 Jan 2012 03:24:07 PM UTC, comment #17: 

I haven't looked at the zoom problem, but I do see an error with trying to click and drag on the plot window when log axes are involved.

The problem there seems to be that moving the plot needs to be done in terms of screen coordinates but the delta_x delta_y that are given to axes_properties::translate_view are based on data values, and we don't know where the mouse is.  For example, if you have a plot that goes from 10^1 to 10^3 and delta is 10, it has a much different meaning if the mouse position is near 10^1 vs. 10^3, but the translate_view function doesn't have that information.  So even if you adjust delta for the log scale, I don't see how the calculation of the new limits can be correct.

I don't see how to untangle this mess without major surgery, but maybe one of you will see a way to make it work.  OTOH, if you do, I'm afraid that the result will be even messier and harder to maintain than what we currently have.

John W. Eaton <jwe>
Group administrator
Thu 19 Jan 2012 07:21:45 PM UTC, comment #16: 

In particular, I think the class log_scaler::scale may not behave well if it is fed weird data.

Rik <rik5>
Group administrator
Thu 19 Jan 2012 07:18:18 PM UTC, comment #15: 

I think the problem lies in graphics.cc.  You might want to take a look at these changesets in Mercurial which appear to be related.


changeset:   13757:1e81e2e30af3
user:        John W. Eaton <jwe@octave.org>
date:        Wed Oct 26 17:36:54 2011 -0400
files:       src/graphics.cc
description:
default limits for logscale plots

* graphics.cc (default_lim): New optional argument, logscale.
Return [0.1, 1.0] if logscale is true.
(axes::properties::get_axis_limits): Return default limits if min/max
values are at their initial values.


changeset:   13756:6dfebfa334cb
user:        John W. Eaton <jwe@octave.org>
date:        Wed Oct 26 14:19:54 2011 -0400
files:       liboctave/dMatrix.cc liboctave/dMatrix.h liboctave/dNDArray.cc liboctave/dNDArray.h liboctave/fMatrix.cc liboctave/fMatrix.h liboctave/fNDArray.cc liboctave/fNDArray.h liboctave/lo-mappers.h liboctave/mx-inlines.cc src/graphics.cc src/graphics.h.in
description:
allow negative data log plots with OpenGL+FLTK graphics (bug #34232)

* mx-inlines.cc (mx_inline_any_positive): New function.
* lo-mappers.h (xpositive_sign (double), xpositive_sign (float)):
New functions.
* fNDArray.h, fNDArray.cc (FloatNDArray::any_element_is_positive):
New function.
* fMatrix.h, fMatrix.cc (FloatMatrix::any_element_is_positive):
New function.
* dNDArray.h, dNDArray.cc (NDArray::any_element_is_positive):
New function.
* dMatrix.h, dMatrix.cc (Matrix::any_element_is_positive):
New function.
* graphics.h.in (log_scaler::do_neg_scale): New function.
(log_scaler::scale (const Matrix&) const,
log_scaler::scale (const NDArray&) const): Call do_neg_scale if no
array elements are positive.
* graphics.cc (axes::properties::get_axis_limits): Omit zero from
positive values for log plots.  Correctly widen range for all negative
log plots.



Rik <rik5>
Group administrator
Thu 19 Jan 2012 06:58:08 PM UTC, comment #14: 

loglog plots also crash on zoom with mouse wheel.

I am using gdb an bt to see if there is a common point where these crashes intersect.

Doug Stewart <dastew>
Thu 19 Jan 2012 06:47:26 PM UTC, comment #13: 

loglog plots also crash on panning

Doug Stewart <dastew>
Thu 19 Jan 2012 06:15:39 PM UTC, comment #12: 

Thanks for your help Rik
I will look at the log problem.

Doug Stewart <dastew>
Thu 19 Jan 2012 05:58:04 PM UTC, comment #11: 

Doug,

Thanks for the patch.  I modified it slightly to conform to Octave coding standards.  I did the following

1) Use spaces, rather than tabs, with an indent of 2
2) Limit lines, if possible, to less than 80 characters
3) Commit message changed to Octave syntax.  We always refer to the bug # in the tracker in the first line of the commit message.

If you want to become a regular contributor try the "Tips and Standards" and "Contributing Guidelines" chapters in the Octave manual.

I also moved the mark_modified () call outside of the if block which checks for a minimum size selection region.  Otherwise, the screen is not updated if the selection area was too small and this will leave little blue rectangles on the plot where the user failed to make a proper zoom selection.

I committed the changeset here if you want to take a look. (http://hg.savannah.gnu.org/hgweb/octave/rev/358b59706656)

So, this solves the first part of the problem which Doug reported.  I still have a problem with right-mouse zooming with logarithmic axes and I am going to re-title the bug report to reflect that.

Rik <rik5>
Group administrator
Thu 19 Jan 2012 02:43:41 PM UTC, comment #10: 

I have attached a fix for this problem.

The problem was that if you tried to zoom in using the right mouse button, but did not drag the mouse , then the zoom factor would be infinite and cause a crash.

I have set the smallest zoom box to be 4X4 pixels whis gives a nice maximum zoom and stops very large unintentional zooms.

(file #24847)

Doug Stewart <dastew>
Fri 13 Jan 2012 07:48:27 AM UTC, comment #9: 

The bug seems to be same as
http://savannah.gnu.org/bugs/?35159

Tatsuro MATSUOKA <tmacchant>
Thu 12 Jan 2012 06:22:09 PM UTC, comment #8: 

I've got a hunch this has nothing to do with the bode plot code, but rather with logarithmic axes.  The following code crashes for me.


loglog (1:10, 1:10);
# Now use the right mouse button to select a portion of the plot #
# Octave then stops with the following message #
error: memory exhausted or requested size too large for range of Octave's index type -- trying to return to prompt


If someone else can verify this behavior then I think we can make the bug report more specific. 

The handling of logarithmic axes in FLTK has been a problem in the past. 

Rik <rik5>
Group administrator
Thu 12 Jan 2012 01:35:33 AM UTC, comment #7: 

I'm marking this as a problem for any operating system. However, I'm not able to duplicate it on MacOS using fltk 1.3.


Ben Abbott <bpabbott>
Group Member
Thu 12 Jan 2012 12:25:33 AM UTC, comment #6: 

Yes it crashes 3.6.0 the same way.

Doug Stewart <dastew>
Thu 12 Jan 2012 12:15:23 AM UTC, comment #5: 

ok. Changing the category.

Doug does 3.6.0 crash for you as well ?

Ben Abbott <bpabbott>
Group Member
Thu 12 Jan 2012 12:12:22 AM UTC, comment #4: 

I have done some more investigating of this problem.
It is not just with the Bode plot. It seems to be a problem with any plot. I tried step, impulse and bode and plot, and they seemed to work the same. With any plot window you can resize it and zoom with the mouse wheel, and zoom with the right button, but if you press and release the right button without moving the mouse, then you get the crash. But if you do some activity with the left button (pan) then it wont crash on the right button until you do it 2 or 3 times.

So there is a problem when the mouse has not moved and some kind of a stack problem.
Doug Stewart

Doug Stewart <dastew>
Wed 11 Jan 2012 11:51:40 PM UTC, comment #3: 

It is with fltk only.
gnuplot does not crash for me.
Doug

Doug Stewart <dastew>
Wed 11 Jan 2012 11:29:45 PM UTC, comment #2: 

Does this work with fltk, but not with gnuplot ?

Ben Abbott <bpabbott>
Group Member
Wed 11 Jan 2012 08:28:44 PM UTC, comment #1: 

this also crashes on octave  3.5.92   and Ubuntu 10.04


octave:10> g1 = tf([200],conv([1 1],[1 4]))

Transfer function 'g1' from input 'u1' to output ...

           200    
 y1:  -------------
      s^2 + 5 s + 4

Continuous-time model.
octave:11> bode(g1)
octave:12> terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
panic: Aborted -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Aborted
doug@doug-desktop:~/oct395/octave-3.5.92$


Doug Stewart

Doug Stewart <dastew>
Wed 11 Jan 2012 08:14:53 PM UTC, original submission:  

I am using the Octave Control Systems Toolbox, http://www.obihiro.ac.jp/~suzukim/masuda/octave/html/octave_125.html.

When I use the bode function, which plots two graphs, the program crashes when I use the right mouse click zoom. I have tried zooming in on graphs from other functions in the control package and I haven't had the same problem.

Here is the code I am using:

g1 = tf([200],conv([1 1],[1 4])) #This is a transfer funcion I am interested in

bode(g1)

John <jjo>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #24954:  diffs.txt added by jwe (5KiB - text/plain)
file #24847:  zoom.patch added by dastew (3KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by tmacchant (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by jjo (Submitted the item)
  • -email is unavailable- added by jjo
  •  

    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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-04 rik5 StatusDuplicate Fixed
        Open/ClosedOpen Closed
    2012-02-02 jwe Attached File- Added diffs.txt, #24954
    2012-01-19 rik5 SummaryPlotted Figure crashing FLTK plot figure crashes when using right-mouse zoom and logarithmic axes
    2012-01-19 dastew Attached File- Added zoom.patch, #24847
    2012-01-13 bpabbott StatusConfirmed Duplicate
    2012-01-12 rik5 StatusNone Confirmed
    2012-01-12 bpabbott Release3.4.3 dev
        Operating SystemMicrosoft Windows Any
    2012-01-12 bpabbott CategoryPlotting with gnuplot Plotting with OpenGL
    2012-01-11 jjo Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code