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: Rik
Subject: [Octave-bug-tracker] [bug #47699] FLTK can segfault after using legend
Date: Thu, 28 Apr 2016 03:21:13 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0

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

I applied Lachlan's patch, on default, and it does fix the problem.  I'm
reluctant to push it, however, because I don't understand the root cause. 
Shouldn't objects which are being deleted refrain from executing callbacks? 
Octave seems to have that already in delete_object in graphics.cc.


      // Don't do recursive deleting, due to callbacks
      if (! go.get_properties ().is_beingdeleted ())
        {
          graphics_handle parent_h = go.get_parent ();

          graphics_object parent_go = gh_manager::get_object (parent_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

          gh_manager::free (h);

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

          Vdrawnow_requested = true;
        }


Alternatively, even if Fdrawnow is called, shouldn't it detect that a graphics
object is invalid before re-drawing it?  We seem to have that as well.


          Matrix hlist = gh_manager::figure_handle_list (true);

          for (int i = 0; i < hlist.numel (); i++)
            {
              graphics_handle h = gh_manager::lookup (hlist(i));

              if (h.ok () && h != 0)
                {
                  graphics_object go = gh_manager::get_object (h);
                  figure::properties& fprops
                    = dynamic_cast <figure::properties&> (go.get_properties
());

                  if (fprops.is_modified ())
                    {
                      if (fprops.is_visible ())
                        {
                          gh_manager::unlock ();

                          fprops.get_toolkit ().redraw_figure (go);

                          gh_manager::lock ();
                        }

                      fprops.set_modified (false);
                    }
                }
            }


Maybe besides checking the modified status, it should check whether it is
being deleted before calling redraw_figure?


    _______________________________________________________

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]