[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #52666] Segfault when closing a figure inside a "deletefcn" callback
Date: Thu, 14 Dec 2017 21:10:41 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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

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)
          // 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

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


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]