[Octave-bug-tracker] [bug #52666] Segfault when closing a figure inside a "deletefcn" callback

[Dan Sebald]

Follow-up Comment #6, bug #52666 (project octave):

I tried this.  I'm seeing 100% CPU as well.  This could be an infinite loop of
the line deletefcn calling its parent's close, which calls the line's
deletefcn, which calls its parent's close, etc.  Of course, something should
break along the way in terms of freeing memory multiple times.  Perhaps it is
only under the debugger when some bad memory access causes a segmentation
fault.

What comes to mind is if the parent figure has a list of items it contains, it
should remove the pointer for an item from that list and then delete it rather
than delete it and then remove the pointer from the list.  If you follow...
hold on, let me look at the code since Rik narrowed things down.

And here's a note in graphics.cc:


static void
delete_graphics_object (const graphics_handle& h)
{
[snip]
          // NOTE: free the handle before removing it from its parent's
          //       children, such that the object's state is correct when the
          //       deletefcn callback is executed
[snip]
}


So, how is it supposed to prevent recursive loop?  Well, there is this


      // Don't do recursive deleting, due to callbacks
      if (! go.get_properties ().is_beingdeleted ())


My guess would be that somehow that "is_beingdeleted" is failing...  OK, the
way this works is that "beingdeleted" is a parameter in the base_properties
and is/get/set control that parameters, so the


       bp.set_beingdeleted (true);


is set in some function "gh_manager::do_free".  Hmm, I suspect that
set_beingdeleted() at that point might be too late in the chain of events to
prevent a recursion.  Wouldn't it seem like that variable should be set
immediately prior to calling the routine that delete's the g.o.?  Have to put
some thought into where this should be set, and maybe if it should be set in
multiple places, e.g., the two scenarios of manually, directly deleting a g.o.
via "delete(go)" versus the delete initiating from a parent being closed or
deleted.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52666>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/