bugGNU Octave - Bugs: bug #48186, delete(allchild(fig)) in a...

 
 

bug #48186: delete(allchild(fig)) in a "deletefcn" callback raises error

Submitted by:  Guillaume <gyom>
Submitted on:  Thu 09 Jun 2016 04:23:51 PM UTC  
 
Category:  Plotting with OpenGL Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Confirmed Assigned to:  None
Originator Name:  Guillaume Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 05 Nov 2020 09:49:39 PM UTC, comment #21: 

OK, changing the release tag to "dev".

John W. Eaton <jwe>
Project Administrator
Thu 05 Nov 2020 09:46:50 PM UTC, comment #20: 

See my comment #15 where I agree that I don't think this is a blocker for the 6.1 release.

Rik <rik5>
Project Administrator
Thu 05 Nov 2020 08:03:49 PM UTC, comment #19: 

Is there a quick fix?  If not, then I think we'll have to mark this as a bug to fix for Octave 7.

John W. Eaton <jwe>
Project Administrator
Wed 28 Oct 2020 11:14:31 PM UTC, comment #18: 

The problem seems to be that at some point "allchild" returns handles that "ishghandle" judges invalid:

F = figure('Units','normalized');
h1 = uipanel(F,'Position',[0 0 0.45 1], 'DeleteFcn','disp (ishghandle (allchild (gcbf ())))');
h2 = uipanel(F,'Position',[0.55 0 0.45 1]);
close (F);

This shows that the first handle in the return list (h2) is not valid anymore.

Pantxo Diribarne <pantxo>
Project Member
Mon 26 Oct 2020 07:01:13 AM UTC, comment #17: 

Still crashes Octave 6.0.92

>> __octave_config_info__ ("hg_id")
ans = cc287e633588

Kai Torben Ohlhus <siko1056>
Project Member
Sun 23 Feb 2020 08:54:23 PM UTC, comment #16: 

Using gdb, it seems that when Octave hangs it is caught in a deadlock situation with a mutex.

#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007fd101756098 in __GI___pthread_mutex_lock (mutex=0x7fd0d0104b80) at ../nptl/pthread_mutex_lock.c:113
#2  0x00007fd105ab3ba6 in octave::pthread_mutex::lock (this=0x7fd0d0104b70) at liboctave/util/oct-mutex.cc:135
#3  0x00007fd1079a040f in octave::mutex::lock (this=0x7fffebc55370) at ./liboctave/util/oct-mutex.h:92
#4  0x00007fd1079a04ad in octave::autolock::autolock (this=0x7fffebc55370, m=..., block=true)
    at ./liboctave/util/oct-mutex.h:118
#5  0x00007fd1079d0d75 in QtHandles::Panel::eventFilter (this=0x558c08337560, watched=0x558c07cbbd20,
    xevent=0x7fffebc55770) at libgui/graphics/Panel.cc:188
#6  0x00007fd1021965bc in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x00007fd102f14815 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x00007fd102f1c104 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x00007fd107aa8074 in octave::octave_qapplication::notify (this=0x558c07b7efc0, receiver=0x558c07cbbd20,
    ev=0x7fffebc55770) at libgui/src/octave-qobject.cc:136
#10 0x00007fd1021968d8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007fd102f4c0fb in QWidgetPrivate::sendPendingMoveAndResizeEvents(bool, bool) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x00007fd102f4fed3 in QWidgetPrivate::show_helper() () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x00007fd102f52beb in QWidget::setVisible(bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x00007fd102f52195 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x00007fd1021c60c2 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007fd102f5375b in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x00007fd102ff44de in QFrame::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x00007fd102f1483c in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x00007fd102f1c104 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#20 0x00007fd107aa8074 in octave::octave_qapplication::notify (this=0x558c07b7efc0, receiver=0x558c07cbbd20,
    ev=0x558c08354d70) at libgui/src/octave-qobject.cc:136
#21 0x00007fd1021968d8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x00007fd10219904d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00007fd1021f0263 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x00007fd0fa9e5417 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x00007fd0fa9e5650 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x00007fd0fa9e56dc in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007fd1021ef88f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#28 0x00007fd10219490a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#29 0x00007fd10219d9b4 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x00007fd107aa8a9f in octave::base_qobject::exec (this=0x7fffebc56080) at libgui/src/octave-qobject.cc:278
#31 0x00007fd107ab6868 in octave::qt_application::execute (this=0x7fffebc56200) at libgui/src/qt-application.cc:73
#32 0x0000558c070d68a1 in main (argc=9, argv=0x7fffebc56508) at src/main-gui.cc:106

Rik <rik5>
Project Administrator
Sun 23 Feb 2020 07:27:02 PM UTC, comment #15: 

This isn't desirable, but I don't think it is a Blocker for the 6.1 release.  This is not a common code pattern.  Still, we should see if we could quickly fix this.

More important than a bogus error message, is the fact that this can result in Octave hanging in such a state that only a kill signal from outside the program can stop it.

Placing this code in tst_delete_cb.m and running several times results in a hang.

F = figure('Units','normalized');
h2 = uipanel(F,'Position',[0.55 0 0.45 1]);
h1 = uipanel(F,'Position',[0 0 0.45 1], 'DeleteFcn','delete(allchild(gcbf))');
close (F);

(file #48487)

Rik <rik5>
Project Administrator
Sun 23 Feb 2020 12:49:03 PM UTC, comment #14: 

I can confirm the observation in comment #13.

Re-opening report and marking as blocker for 6.1.

Markus Mützel <mmuetzel>
Project Member
Mon 06 Jan 2020 11:02:25 AM UTC, comment #13: 

I think this report should be reopened. While the code from comment #5 runs fine with 5.1, it returns an error with current dev:

octave:1> F = figure('Units','normalized');
octave:2> uipanel(F,'Position',[0 0 0.45 1], 'DeleteFcn','delete(allchild(gcbf))');
octave:3> uipanel(F,'Position',[0.55 0 0.45 1]);
octave:4> close(F)
error: delete: first argument must be a filename or graphics handle
error: called from
    delete at line 61 column 5
    delete at line 58 column 5
    closereq at line 37 column 5
    close at line 112 column 5

and if you revert the order the two uipanels are created then Octave seems to be stuck in an infinite loop:

octave:1> F = figure('Units','normalized');
octave:2> uipanel(F,'Position',[0.55 0 0.45 1]);
octave:3> uipanel(F,'Position',[0 0 0.45 1], 'DeleteFcn','delete(allchild(gcbf))');
octave:4> close(F)

Guillaume <gyom>
Thu 16 Aug 2018 05:25:34 AM UTC, comment #12: 

The test code from comment #5 now works just fine.  Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Mon 13 Jun 2016 09:59:50 AM UTC, comment #11: 

In Matlab, the order of the creation of the two uipanels does not matter and I don't seen any difference between using "allchild(F)" and "allchild(gcbf)".

Guillaume <gyom>
Fri 10 Jun 2016 05:26:14 PM UTC, comment #10: 

And what if the order of creation is reversed in old Matlab as well?

Does "allchild(F)" in the callback give the same list as "allchild(gcbf)"? Just want to make sure it's not some special view of the figure object that has different properties for the duration of the callback.

Assuming those are both fine, and the order we are doing things is backwards, the change looks like reversing the order of gh_manager::free(h) and parent.remove_child(h) in a few places in graphics.cc. Some other devs more familiar with the graphics system should weigh in on whether this is safe or worth doing.

Mike Miller <mtmiller>
Project Administrator
Fri 10 Jun 2016 04:31:31 PM UTC, comment #9: 

Here is what an 'old' version of Matlab returns:

>> F = figure('Units','normalized');
>> U1 = uipanel(F,'Position',[0 0 0.45 1], 'DeleteFcn','allchild(gcbf),delete(allchild(gcbf))')

U1 =

  173.0011

>> U2 = uipanel(F,'Position',[0.55 0 0.45 1])

U2 =

  174.0011

>> U = allchild(F)

U =

  174.0011
  173.0011
  144.0011
  132.0011
  131.0011
   80.0011
   64.0011
   57.0011
   37.0011
   18.0011
    0.0011

>> close(F)

ans =

  173.0011

(the extra handles correspond to the toolbar and menus)

Guillaume <gyom>
Fri 10 Jun 2016 04:26:50 PM UTC, comment #8: 

Thanks. I notice two things: the first one is that the error depends on the order in which the two uipanels are created. The following returns an error with Octave:

F = figure('Units','normalized');
U1 = uipanel(F,'Position',[0 0 0.45 1], 'DeleteFcn','allchild(gcbf),delete(allchild(gcbf))')
U2 = uipanel(F,'Position',[0.55 0 0.45 1])
U = allchild(F)
close(F)

while this runs fine:

F = figure('Units','normalized');
U1 = uipanel(F,'Position',[0.55 0 0.45 1])
U2 = uipanel(F,'Position',[0 0 0.45 1], 'DeleteFcn','allchild(gcbf),delete(allchild(gcbf))')
U = allchild(F)
close(F)

Matlab behaviour follows in the next comment.

Guillaume <gyom>
Fri 10 Jun 2016 04:25:08 PM UTC, comment #7: 

By the way, there is a comment in the Octave sources dating from 2011 claiming an intentional order of operations here:

> 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


This seems to imply that the decision was made intentionally to delete the child object, which calls its deletefcn callback function, before removing it from the parent's "children" list. So which way is correct?

Mike Miller <mtmiller>
Project Administrator
Fri 10 Jun 2016 04:10:05 PM UTC, comment #6: 

Ok, reopening and retitling to reflect that specific error.

Can you show what the contents of allchild(F) is before and during the callback? Maybe Matlab is removing the uipanel from the children list before calling the deletefcn callback?

Mike Miller <mtmiller>
Project Administrator
Fri 10 Jun 2016 04:02:39 PM UTC, comment #5: 

Thanks, Mike. Sorry, this bug report is confusing because I mentioned two separate issues and the title I chose relate to the second issue that is of lesser importance.

I agree that deleting a deleted handle is not a primary problem and can be left for later when/if graphics handles are implemented as objects.

There is still the issue that the following code returns an error:

F = figure('Units','normalized');
uipanel(F,'Position',[0 0 0.45 1], 'DeleteFcn','delete(allchild(gcbf))');
uipanel(F,'Position',[0.55 0 0.45 1]);
close(F)

while it runs OK even for Matlab versions that implement graphics handles as double.

Guillaume <gyom>
Fri 10 Jun 2016 03:41:12 PM UTC, comment #4: 

I see.

So we are behaving correctly within the constraints of what we have support for currently in Octave.

I don't think there is much point to keeping this open just to remember this for when graphics handle objects are actually implemented.

Mike Miller <mtmiller>
Project Administrator
Fri 10 Jun 2016 09:25:29 AM UTC, comment #3: 

Mike,

your examples throw the error "Invalid or deleted object."

This error is also thrown for the following example in current Matlab versions:

h = figure (42);
delete (42)
delete (42)

The reason why no error is thrown for the original example in comment #0 is probably that recent versions of Matlab return a graphics object instead of a double for handles.

See: http://de.mathworks.com/help/matlab/graphics_transition/graphics-handles-are-now-objects-not-doubles.html

Octave did not (yet?) make this transition.

Markus Mützel <mmuetzel>
Project Member
Fri 10 Jun 2016 09:20:26 AM UTC, comment #2: 

You get this:

>> delete(42)
Error using delete
Invalid or deleted object.

>> delete(pi)
Error using delete
Invalid or deleted object.

In recent Matlab versions, handles are objects:

>> h = figure;
>> delete(h)
>> h
h =
  handle to deleted Figure

allowing for a second silent deletion as in original post. With older Matlab versions, relying on doubles to store handles, you get:

>> h = figure;
>> delete(h)
>> delete(h)
??? Error using ==> delete
Invalid handle object.

i.e. the same error message that you get with delete(42).

I might have added confusion to this thread though as the initial problem is somehow different as older Matlab versions (that behave like Octave regarding deletion of an already deleted handle) do not crash when the figure containing the uipanels is closed.

It seems that the code in graphics.cc (_go_delete_ and delete_graphics_objects) takes care of handles that might have been already deleted by a callback function but it must miss a case.

Guillaume <gyom>
Thu 09 Jun 2016 04:42:11 PM UTC, comment #1: 

What about this in Matlab (in a fresh session with no handles)?

>> delete (42)
>> delete (pi)

No errors or warnings, just silently do nothing?

Mike Miller <mtmiller>
Project Administrator
Thu 09 Jun 2016 04:23:51 PM UTC, original submission:  

Here is a simplified version of a situation I came across:

F = figure('Units','normalized');
uipanel(F,'Position',[0 0 0.45 1], 'DeleteFcn','delete(allchild(gcbf))');
uipanel(F,'Position',[0.55 0 0.45 1]);

Closing the figure removes the right panel then crashes with this error message:

error: delete: first argument must be a filename or graphics handle
error: parse error
error: called from
    delete at line 63 column 5
    delete at line 60 column 5
    closereq at line 42 column 5

In particular, with Octave:

>> h=figure;
>> delete(h)
>> delete(h)
error: delete: first argument must be a filename or graphics handle
error: called from
    delete at line 63 column 5

whereas in Matlab:

>> h=figure;
>> delete(h)
>> delete(h)

Guillaume <gyom>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #48487:  tst_delete_cb.m added by rik5 (166B - text/x-matlab)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by lachlan (Updated the item)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by gyom (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 22 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-05 jwe Release6.0.92 => dev
    2020-10-26 siko1056 Release6.0.90 => 6.0.92
    2020-02-23 rik5 Attached File- => Added tst_delete_cb.m, #48487
        Severity5 - Blocker => 4 - Important
    2020-02-23 mmuetzel Open/ClosedClosed => Open
    2020-02-23 mmuetzel Severity2 - Minor => 5 - Blocker
        Item GroupMatlab Compatibility => Regression
        StatusFixed => Confirmed
        Releasedev => 6.0.90
    2020-01-25 mtmiller Carbon-CopyRemoved 80942 => -
    2018-08-16 rik5 StatusNone => Fixed
        Open/ClosedOpen => Closed
    2016-07-12 lachlan StatusNeed Info => None
    2016-06-10 mtmiller CategoryGUI => Plotting with OpenGL
        Severity3 - Normal => 2 - Minor
        StatusWorks For Me => Need Info
        Open/ClosedClosed => Open
        SummaryDeleting a deleted handle => delete(allchild(fig)) in a "deletefcn" callback raises error
    2016-06-10 mtmiller StatusNeed Info => Works For Me
        Open/ClosedOpen => Closed
    2016-06-09 mtmiller Item GroupNone => Matlab Compatibility
        StatusNone => Need Info

    Back to the top


    Powered by Savane 3.7