[Top][All Lists]

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

[Octave-bug-tracker] [bug #55908] Closing plots much slower in Octave 5.

From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #55908] Closing plots much slower in Octave 5.1.0
Date: Fri, 22 Mar 2019 15:39:28 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Follow-up Comment #12, bug #55908 (project octave):

I noticed the gcbo failure but didn't think to look at this bug report. 
Bisecting showed

The first bad revision is:
changeset:   26935:ead8f91c5556
user:        Markus M?tzel <address@hidden>
date:        Sat Mar 16 22:21:26 2019 +0100
summary:     Improve performance when closing figures (bug #55908).

While trying to find the problem, I also found that I could duplicate the
error with

plot_src_dir = "/my/src/dir/octave/scripts/plot";
dirs = {"appearance", "draw", "util"};
for i = 1:3
  runtests (fullfile (plot_src_dir, dirs{i}));

That helped to significantly speed up bisecting.

I also tried looking at the parents of the graphics object that gcbo returns
in the test but unlike what Rik notes in comment #10, calling get on the first
parent causes Octave to crash with a segfault.

To see what the parent objects were, I changed the test to

%! wtf = gcbo ();                                                             
%! if (! isempty (wtf))                                                       
%!   get (wtf)                                                                
%!   p = get (wtf, 'parent');                                                 
%!   while (! isempty (p))                                                    
%!     get (p)                                                                
%!     p = get (p, 'parent')                                                  
%!   end                                                                      
%! end                                                                        
%! assert (isempty (wtf));                                                    

Here is the output I see:

  gcbo.m ......................................................ans =

  scalar structure containing the fields:

    basevalue =  0.30000
    beingdeleted = off
    busyaction = queue
    buttondownfcn = [](0x0)
    children = [](0x1)
    clipping = on
    createfcn = [](0x0)
    deletefcn = [](0x0)
    handlevisibility = off
    hittest = on
    interruptible = on
    parent = -4117.9
    pickableparts = visible
    selected = off
    selectionhighlight = on
    tag = 
    type = line
    uicontextmenu = [](0x0)
    userdata = [](0x0)
    visible = on
    color =

       0   0   0

    displayname = 
    linejoin = round
    linestyle = -
    linewidth =  0.50000
    marker = none
    markeredgecolor = auto
    markerfacecolor = none
    markersize =  6
    xdata =

       1   3

    xdatasource = 
    ydata =

       0.30000   0.30000

    ydatasource = 
    zdata = [](0x0)
    zdatasource = 

fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault

It looks like a graphics handle is being deleted but not removed from the list
of handles?  Maybe tracing the handles that are created and deleted for this
series of tests with and without the patch could help with debugging?  Limit
the tracing to objects that could be returned by gcbo?


Reply to this item at:


  Message sent via Savannah

reply via email to

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