octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #47699] FLTK can segfault after using legend


From: Lachlan Andrew
Subject: [Octave-bug-tracker] [bug #47699] FLTK can segfault after using legend
Date: Thu, 28 Apr 2016 06:44:32 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0

Follow-up Comment #21, bug #47699 (project octave):

No, the guilt is still mine :(

It turns out that the error is thrown exactly in the second chunk of text Rik
identified:


graphics_object go = gh_manager::get_object (h);
figure::properties& fprops
   = dynamic_cast <figure::properties&> (go.get_properties ());


The problem is that  h  has been partly deleted and so we can't get its
properties, but it is still in hlist, and still passes the test h.ok ().

The only mystery is why this didn't initially show up with qt.  Juan Pablo's
example gives me the error with qt.

We can't refrain from calling callbacks during deletion, since the whole
purpose of the "deletefcn" callback is deletion.  In this case, it is calling
@deletelegend2.

It seems that a lot of care has gone into the sequencing of deletion events
around the callback -- such as the following code:
+verbatim
  // 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
    gh_manager::free (h);

  // A callback function might have already deleted the parent
    if (parent_go.valid_object ())
      parent_go.remove_child (h);


I think the best thing to do is simply not to redraw during deletion.  The
attached patch is possibly a  cleaner approach.  Instead of storing a global
flag, it simply refrains from redrawing if the object of the current callback
is being deleted.

(file #37009)
    _______________________________________________________

Additional Item Attachment:

File name: bug_47699_fltk_close_v3.cset   Size:1 KB


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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