bugGNU Octave - Bugs: bug #35857, Octave crashes when plotting with...

 
 

bug #35857: Octave crashes when plotting with units = normalized

Submitter:  Muhali <muhali>
Submitted:  Thu 15 Mar 2012 09:13:36 PM UTC
   
 
Category:  Plotting Severity:  5 - Blocker
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
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

Sun 26 Apr 2015 02:33:54 PM UTC, comment #21: 

Marking bug as fixed and closing report.

Rik <rik5>
Group administrator
Sun 26 Apr 2015 02:28:42 PM UTC, comment #20: 

OK to close this report?

John W. Eaton <jwe>
Group administrator
Wed 08 Apr 2015 08:52:42 PM UTC, comment #19: 
John W. Eaton <jwe>
Group administrator
Wed 08 Apr 2015 04:42:19 PM UTC, comment #18: 

I'll do it soon.

John W. Eaton <jwe>
Group administrator
Wed 08 Apr 2015 04:00:11 PM UTC, comment #17: 

I verified the patch.  I'd commit it so we can finally get to releasing 4.0.

Rik <rik5>
Group administrator
Wed 08 Apr 2015 03:36:07 PM UTC, comment #16: 

If someone can verify that the patch linked in comment #15 works, then I'll add a commit message and push the changeset.

John W. Eaton <jwe>
Group administrator
Wed 08 Apr 2015 03:34:28 PM UTC, comment #15: 

I'm attaching another patch.  It attempts to fix the label positioning for all possible unit values and also correctly inherit defaults for the axes labels.

Inheriting defaults wasn't working for the axes labels because they are created inside the axes constructor and so the parent (axes) object wasn't fully constructed and inserted into the gh_manager map of handles -> objects, so looking up parent objects could not work correctly.

I'm still not sure that what I've done in the attached patch is the best solution, but it seems to work for me.

(file #33597)

John W. Eaton <jwe>
Group administrator
Mon 06 Apr 2015 12:58:02 AM UTC, comment #14: 


definitely, yes. no longer blocker!

Michael Godfrey <godfrey>
Group Member
Mon 06 Apr 2015 12:45:52 AM UTC, comment #13: 

I think I like the first patch better.  With the second patch, if I do a mouse click after the plot() command but before the title() command it resizes the axes to some strange value.

With the crash fixed I think we can downgrade this to "Incorrect Result" and change the Severity back to normal so this bug doesn't delay the 4.0 release.

Rik <rik5>
Group administrator
Sat 04 Apr 2015 08:47:04 PM UTC, comment #12: 

OK, I'm attaching a new patch.  The only change is to text::properties::update_units so that an auto positionmode property is preserved.  That at least makes the units not be (0,0,0), but it does not make them normalized.  Instead, they still seem to be the "data" values.  I tried to add a call to convert_position in the axes::properties::update_title_position function but I don't seem to know what I'm doing with the conversions/transformations.  Maybe someone who understands this code better can see what to do.

(file #33539)

John W. Eaton <jwe>
Group administrator
Sat 04 Apr 2015 05:54:25 PM UTC, comment #11: 

@jwe: The diff prevents the segfault, but the title and [xyz]labels all show up at position (0,0,0).  The original code shows the problem.


set(0, "defaulttextunits", "normalized") ;
plot(0.05*[0 1])
title("T1") ;


The ordinary code, assuming no defaulttextunits, works correctly


plot(0.05*[0 1])
title("T1") ;
ht = get (gca, "title");
get (ht, "position")
ans =

   1.500000   0.051457   0.500000

set (ht, "units", "normalized");
get (ht, "position")
ans =

   0.50000   1.02914   0.00000


By setting some breakpoints I can see that the position field is updated in normal 'data' mode. (It starts with update_axes_layout->update_ticklength->update_xlabel_position->set_position).  In fact, the first initialization() which is called through _go_axes_ works fine.  It is the subsequent call to _go_axes_init_ which deletes the label objects and then re-creates them that causes the problem.  The value in the override of the position is definitely (0,0,0).

Backtrace is:


#0  text::properties::set_position (this=0x7fffd853c4f0, val=...) at corefcn/graphics.h:7761
#1  0x00007ffff6fe52a8 in text::properties::update_units (this=0x7fffd853c4f0)
    at corefcn/graphics.cc:8180
#2  0x00007ffff701719a in text::properties::set_units (this=0x7fffd853c4f0, val=...)
    at corefcn/graphics.h:8217
#3  0x00007ffff6f5a28e in text::properties::set (this=0x7fffd853c4f0, pname_arg=..., val=...)
    at corefcn/graphics-props.cc:3315
#4  0x00007ffff7004221 in base_graphics_object::set (this=0x7fffd853c4e0, pname=..., pval=...)
    at corefcn/graphics.h:2993
#5  0x00007ffff6ef8a66 in base_properties::set_from_list (this=0x7fffd853c4f0, obj=...,
    defaults=...) at corefcn/graphics.cc:2882
#6  0x00007ffff70041a7 in base_graphics_object::set_from_list (this=0x7fffd853c4e0, plist=...)
    at corefcn/graphics.h:2985
#7  0x00007ffff700661d in root_figure::override_defaults (this=0x655760, obj=...)
    at corefcn/graphics.h:3794
#8  0x00007ffff70050c8 in graphics_object::override_defaults (this=0x7fffdc9141b0, obj=...)
    at corefcn/graphics.h:3264
#9  0x00007ffff6ef9762 in base_properties::override_defaults (this=0x7fffd84acc50, obj=...)
    at corefcn/graphics.cc:3066
#10 0x00007ffff7009ea1 in figure::override_defaults (this=0x7fffd84acc40, obj=...)
    at corefcn/graphics.h:4918
#11 0x00007ffff70050c8 in graphics_object::override_defaults (this=0x7fffdc914240, obj=...)
    at corefcn/graphics.h:3264
#12 0x00007ffff6ef9762 in base_properties::override_defaults (this=0x7fffd84dbdb0, obj=...)
    at corefcn/graphics.cc:3066
#13 0x00007ffff70138c5 in axes::override_defaults (this=0x7fffd84dbda0, obj=...)
    at corefcn/graphics.h:7188
#14 0x00007ffff70050c8 in graphics_object::override_defaults (this=0x7fffdc9142d0, obj=...)
    at corefcn/graphics.h:3264
#15 0x00007ffff6ef9762 in base_properties::override_defaults (this=0x7fffd853c4f0, obj=...)
    at corefcn/graphics.cc:3066
#16 0x00007ffff7004139 in base_graphics_object::override_defaults (this=0x7fffd853c4e0, obj=...)
    at corefcn/graphics.h:2974
#17 0x00007ffff6fed071 in gh_manager::do_make_graphics_handle (this=0x654d10, go_name=..., p=...,
    integer_figure_handle=false, do_createfcn=false, do_notify_toolkit=true)
    at corefcn/graphics.cc:9131
#18 0x00007ffff7028e26 in gh_manager::make_graphics_handle (go_name=..., parent=...,
    integer_figure_handle=false, do_createfcn=false, do_notify_toolkit=true)
    at corefcn/graphics.h:13239
#19 0x00007ffff6fc9b36 in axes::properties::set_defaults (this=0x7fffd84dbdb0, obj=..., mode=...)
    at corefcn/graphics.cc:5077
#20 0x00007ffff7013a67 in axes::set_defaults (this=0x7fffd84dbda0, mode=...)
    at corefcn/graphics.h:7211
#21 0x00007ffff700516e in graphics_object::set_defaults (this=0x7fffdc9156c0, mode=...)
    at corefcn/graphics.h:3290
#22 0x00007ffff6ff4730 in F__go_axes_init__ (args=...) at corefcn/graphics.cc:10736


More to the point,


get (0, 'defaulttextposition')
ans =

   0   0   0


If I change 'defaultextposition' to something reasonable for normalized units ([0.5, 0.5, 0]) then the label shows up correctly (middle of screen).

I tried


hx = get (gca, 'xlabel');
set (hx, 'positionmode', 'auto');


but this may be meant for something else because it set the position value in "data" units completely ignoring the "normalized" value on xlabel.



Rik <rik5>
Group administrator
Sat 04 Apr 2015 07:54:59 AM UTC, comment #10: 

If it may help there is a method that lets you retrieve parent defaults:


void build_user_defaults_map (pval, go_name)


I was planning to rewrite "override_defaults" using this (in the future).

Pantxo Diribarne <pantxo>
Group Member
Fri 03 Apr 2015 11:31:18 PM UTC, comment #9: 

Rik, thanks for all that info.  I was headed in that direction, but I think you definitely saved me some time.

I'm attaching a patch and hoping that the following explains it at least a little.

OK, so there are a couple of things happening here.

One is that we call


  xproperties.override_defaults (*this);


from inside constructors and then expect to be able to get the actual type of "this", but since "this" is being used before it is fully constructed, it is just a pointer to the base type.  I guess C++ wizards would know that you can't dispatch to virtual functions from inside a constructor?

So that makes the call to valid_object in override_defaults return false because it is always the function from the base class.  Oops.  My patch avoids this problem by moving the call to override_defaults outside of the constructor.  But I think a better solution would be a way to apply defaults from the parent objects from inside the constructor.

The second issue was that we were doing something like this:


  delete_children (true);

  xlabel = gh_manager::make_graphics_handle ("text", ...);


but while constructing the new text object, we tried to update positions of xlabel, ylabel, etc.  That failed because we were accessing the xlabel object that was no longer valid, but apparently the handle was still accessible somehow.  In any case, I worked around this problem by first invalidating the handles, then constructing them.  At the point inside the construction of these objects where the position is updated, I just skip that if the handles are not valid.  Then I call the update functions in the axes::properties::set_defaults function after xlabel, ylabel, etc. are otherwise fully initialized.

Please take a look at the patch.  I'm sure it could be improved, but it seems to avoid the crash for me.

(file #33523)

John W. Eaton <jwe>
Group administrator
Fri 03 Apr 2015 07:52:56 PM UTC, comment #8: 

I've single-stepped through a lot of code and figured a bit about what is happening.

Using the original example:


set (0, "defaulttextunits", "normalized");
plot (0.05*[0 1])


The first call to set is fine.  The plot call invokes newplot() to prepare the figure and axes.  At the end of newplot this involves calling


__go_axes_init__ (ca, "replace");
__request_drawnow__ ();


The backtrace of interest is


#0  text::properties::update_units (this=0x7fffd853c700) at corefcn/graphics.cc:8150
#1  0x00007ffff7017036 in text::properties::set_units (this=0x7fffd853c700, val=...)
    at corefcn/graphics.h:8215
#2  0x00007ffff6f5a238 in text::properties::set (this=0x7fffd853c700, pname_arg=..., val=...)
    at corefcn/graphics-props.cc:3315
#3  0x00007ffff700404b in base_graphics_object::set (this=0x7fffd853c6f0, pname=..., pval=...)
    at corefcn/graphics.h:2991
#4  0x00007ffff6ef8a10 in base_properties::set_from_list (this=0x7fffd853c700, obj=..., defaults=...)
    at corefcn/graphics.cc:2885
#5  0x00007ffff7003fd1 in base_graphics_object::set_from_list (this=0x7fffd853c6f0, plist=...)
    at corefcn/graphics.h:2983
#6  0x00007ffff7006447 in root_figure::override_defaults (this=0x655760, obj=...)
    at corefcn/graphics.h:3792
#7  0x00007ffff7004ef2 in graphics_object::override_defaults (this=0x7fffdc914040, obj=...)
    at corefcn/graphics.h:3262
#8  0x00007ffff6ef970c in base_properties::override_defaults (this=0x7fffd84ad360, obj=...)
    at corefcn/graphics.cc:3069
#9  0x00007ffff7009cf9 in figure::override_defaults (this=0x7fffd84ad350, obj=...)
    at corefcn/graphics.h:4916
#10 0x00007ffff7004ef2 in graphics_object::override_defaults (this=0x7fffdc9140d0, obj=...)
    at corefcn/graphics.h:3262
#11 0x00007ffff6ef970c in base_properties::override_defaults (this=0x7fffd84dc5d0, obj=...)
    at corefcn/graphics.cc:3069
#12 0x00007ffff7013735 in axes::override_defaults (this=0x7fffd84dc5c0, obj=...)
    at corefcn/graphics.h:7186
#13 0x00007ffff7004ef2 in graphics_object::override_defaults (this=0x7fffdc914160, obj=...)
    at corefcn/graphics.h:3262
#14 0x00007ffff6ef970c in base_properties::override_defaults (this=0x7fffd853c700, obj=...)
    at corefcn/graphics.cc:3069
#15 0x00007ffff70181a4 in text::text (this=0x7fffd853c6f0, mh=..., p=...) at corefcn/graphics.h:8463
#16 0x00007ffff6eebd00 in make_graphics_object_from_type (type=..., h=..., p=...)
    at corefcn/graphics.cc:1019
#17 0x00007ffff6fece8d in gh_manager::do_make_graphics_handle (this=0x654d10, go_name=..., p=...,
    integer_figure_handle=false, do_createfcn=false, do_notify_toolkit=true) at corefcn/graphics.cc:9096
#18 0x00007ffff7028eac in gh_manager::make_graphics_handle (go_name=..., parent=...,
    integer_figure_handle=false, do_createfcn=false, do_notify_toolkit=true) at corefcn/graphics.h:13237
#19 0x00007ffff6fc9a8c in axes::properties::set_defaults (this=0x7fffd84dc5d0, obj=..., mode=...)
    at corefcn/graphics.cc:5075
#20 0x00007ffff70138d7 in axes::set_defaults (this=0x7fffd84dc5c0, mode=...) at corefcn/graphics.h:7209
#21 0x00007ffff7004f98 in graphics_object::set_defaults (this=0x7fffdc9156c0, mode=...)
    at corefcn/graphics.h:3288
#22 0x00007ffff6ff459c in F__go_axes_init__ (args=...) at corefcn/graphics.cc:10706



text::properties::update_units (void)
{
  if (! units_is ("data"))
    {
      set_xliminclude ("off");
      set_yliminclude ("off");
      set_zliminclude ("off");
    }

  Matrix pos = get_position ().matrix_value ();

  pos = convert_text_position (pos, *this, cached_units, get_units ());
  // FIXME: if the current axes view is 2D, then one should
  // probably drop the z-component of "pos" and leave "zliminclude"
  // to "off".
  set_position (pos);


The initial position returned in pos is (0,0,0).  The value of pos after convert_text_position() is an empty matrix.  The subsequent call of set_position (pos) then causes a chain of errors.

The top of the convert_text_position() function is shown below.


static Matrix
convert_text_position (const Matrix& pos, const text::properties& props,
                       const caseless_str& from_units,
                       const caseless_str& to_units)
{
  graphics_object go = gh_manager::get_object (props.get___myhandle__ ());
  graphics_object ax = go.get_ancestor ("axes");

  Matrix retval;

  if (ax.valid_object ())


What happens is that ax.valid_object () returns false, and so retval assumes the default value of 2-D empty matrix.  Why is the axes not valid?  That is the question.  I hacked a solution by using an else clause off the if statement and returning the input pos if the axis is not valid.  This works and stops the segfault, but doesn't put the labels in the correct location.

The chain starts in axes::properties::set_defaults in graphics.cc.  The first thing the code does is delete all the axes children.  This succeeds.  It is the first call to make_graphics_handle that fails.  Maybe the problem is that somehow the adoption needs to take place first in order for get_ancestor ("axes") to return a valid object.


delete_children (true);

xlabel = gh_manager::make_graphics_handle ("text", __myhandle__,
                                           false, false);
ylabel = gh_manager::make_graphics_handle ("text", __myhandle__,
                                           false, false);
zlabel = gh_manager::make_graphics_handle ("text", __myhandle__,
                                           false, false);
title = gh_manager::make_graphics_handle ("text", __myhandle__,
                                          false, false);
adopt (xlabel.handle_value ());
adopt (ylabel.handle_value ());
adopt (zlabel.handle_value ());
adopt (title.handle_value ());




Rik <rik5>
Group administrator
Thu 19 Feb 2015 12:27:36 PM UTC, comment #7: 

Hi,

@Rik: the crash also occurs for me with absolute coordinates such as "centimeters". The "units" property is supposed to be used for interpreting the position, not the size of the text object.

I still don't know why but it is related to deleting/recreating labels and title when using newplot function on an axes object that has "nextplot" = "replace".

The following doesn't crash Octave but doesn't set the expected units neither.


set(0, "defaulttextunits", "normalized") ;
axes (); hold on;
plot(0.05*[0 1]);
yl = ylabel ("foo");
get (yl, "units") ##-> "data"


Now another question is whether default text object properties should be applied to axes labels and titles. Those object are not meant to be manipulated the same way as regular text objects. What if someone changes the "defaulttextposition" ... I'll check this in Matlab at work.


Pantxo Diribarne <pantxo>
Group Member
Sun 15 Feb 2015 03:58:56 PM UTC, comment #6: 

This still crashes Octave, but the code combination is rare.  Most people use an absolute size such as points, inches, or centimeters when setting sizes.  I'm not going to require that this be fixed before the 4.0 release.

Rik <rik5>
Group administrator
Fri 30 Jan 2015 04:34:51 PM UTC, comment #5: 

I am raising the severity and changing this bug back to a crash, because it now does crash the Octave GUI using Qt plotting.

The errors remain for both Gnuplot and FLTK based plotting.

Mike Miller <mtmiller>
Group Member
Fri 11 Oct 2013 04:56:13 PM UTC, comment #4: 

After this changeset fixing validation of properties to set (http://hg.savannah.gnu.org/hgweb/octave/rev/94dd9bba06a0) I no longer get a segfault.  Octave still issues horrible error messages and won't plot anything properly until you remove the "normalized" property (or set it to "data") with


set(0, "defaulttextunits", "remove");
 or
set(0, "defaulttextunits", "data");


Still, this no longer leads to a crash so I'm changing the Item Group to "Incorrect Result" and this will no longer stop the 3.8 release.

Rik <rik5>
Group administrator
Sun 25 Mar 2012 08:44:42 PM UTC, comment #3: 

Bug #35856 has been fixed on the development branch but the code in this report still crashes Octave.  Running under gdb and looking at the crash, this seems to be related to default properties and order of initialization.  I'm going to mark this postponed as Michael will be looking into that at the end of the summer.

Rik <rik5>
Group administrator
Fri 16 Mar 2012 12:02:13 AM UTC, comment #2: 

(opps) I expect this is a more severe example of

https://savannah.gnu.org/bugs/?35856

Ben Abbott <bpabbott>
Group Member
Fri 16 Mar 2012 12:00:41 AM UTC, comment #1: 

I expect this is a more severe example of

Ben Abbott <bpabbott>
Group Member
Thu 15 Mar 2012 09:13:36 PM UTC, original submission:  

This code


set(0, "defaulttextunits", "normalized") ;
plot(0.05*[0 1])
title("T1") ;


crashes octave (using bec37a92cb3b tip).

Muhali <muhali>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33597:  diffs-3.txt added by jwe (12KiB - text/plain)
file #33539:  diffs-2.txt added by jwe (9KiB - text/plain)
file #33523:  diffs.txt added by jwe (8KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by mtmiller (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 jordigh (Updated the item)
  • -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 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-09-28 jwe DependenciesRemoved dependency from bugs #61238 -
    2021-09-28 jwe Dependencies- bugs #61238 is dependent
    2015-04-26 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2015-04-08 jwe StatusConfirmed Patch Submitted
    2015-04-08 jwe Attached File- Added diffs-3.txt, #33597
    2015-04-04 jwe Attached File- Added diffs-2.txt, #33539
    2015-04-03 jwe Attached File- Added diffs.txt, #33523
    2015-01-30 mtmiller Summarycrash with units = normalized Octave crashes when plotting with units = normalized
    2015-01-30 mtmiller Severity3 - Normal 5 - Blocker
        Item GroupIncorrect Result Segfault, Bus Error, etc.
        StatusPostponed Confirmed
    2013-10-11 rik5 Item GroupSegfault, Bus Error, etc. Incorrect Result
    2012-03-25 rik5 StatusConfirmed Postponed
        Carbon-Copy- Added -email is unavailable-
    2012-03-15 jordigh StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code