Fri 05 Aug 2016 02:28:45 PM UTC, comment #14:
Can this bug report be closed?
|
Thu 28 Jul 2016 08:48:31 PM UTC, comment #13:
I tested you fix and it seems to work!
I ran my old test file that crashed, and now it does not crash for me.
|
Thu 28 Jul 2016 08:20:13 PM UTC, comment #12:
I checked in the following changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/e68128601f5e
This seems to fix the problem for me. Maybe it will fix other crashes with QtHandles code. I didn't do an extensive check, so there may be other places where attempts are made to use invalid graphics objects that also need to be fixed similarly. If so, then maybe we need a cleaner way to do this other than cluttering up the code with repeated checks for valid objects.
|
Fri 15 Jul 2016 11:42:56 AM UTC, comment #11:
Here is a freshened patch, reflecting the change from variable name "application" to "qt_app".
(file #37886)
|
Sat 02 Jul 2016 11:42:50 AM UTC, comment #10:
Thanks for testing the patch, Doug.
You're right that the error occurred earlier and just couldn't be seen due to the crash. Rik reported it in the original bug report -- it can be seen by running with --no-gui.
There is a race condition that needs to be fixed, but I don't see that as a blocker for 4.2.0, whereas the crash is. Others can certainly overrule that opinion.
|
Sat 02 Jul 2016 11:26:53 AM UTC, comment #9:
I tried your patch and it does stop the crashing, but now I see this error message:
error: base_graphics_object::get_properties: invalid graphics object
This message was not seen before, probably because the crash was fast, and the window was gone before we could see this error message.
When I single stepped through the prog. I did not get the error message.
I added a delay like:
H = findall(allchild(F),'flat');
pause(.5);
delete(H);
and this reduced the probability of the error happening.
|
Wed 29 Jun 2016 01:11:33 PM UTC, comment #8:
There are two components to this bug:
1. Why is an error being thrown?
2. Why is it not being caught?
I think that the answer to the second question is that the error is being thrown from the Qt thread, which doesn't have a try/catch around the code being executed. I propose that we put try/catch around any callbacks executed by that thread, as per the attached patch.
This doesn't solve the fundamental problem, but it stops it from crashing.
I also got a stack trace from before the throw. The main thing of interest is that it goes through
(file #37622)
|
Wed 29 Jun 2016 12:27:27 PM UTC, comment #7:
Ah yes. I can see it now. I'll look into it.
|
Wed 29 Jun 2016 10:14:30 AM UTC, comment #6:
I made a script that has
bad_plot
bad_plot
bad_plot
bad_plot
and this works but if I add one more call to bad_plot then it does a hard crash right out of octave.
hg id 9e992b9ffc5f
Ubuntu 16.04
|
Wed 29 Jun 2016 07:48:40 AM UTC, comment #5:
This works for me with the current head (albeit with a few unrelated patches).
Can someone (Avinoam?) confirm that the issue no longer occurs?
|
Tue 24 Nov 2015 12:37:53 AM UTC, comment #4:
Found another bug report, #44339, which looks to be the same behavior with uipanel and delete.
|
Tue 24 Nov 2015 12:23:31 AM UTC, comment #3:
Doubtless this is a race condition. I experimented with different sleep delays of 10ms, 100ms, 200ms. The smallest delay exhibits a failure after ~8 iterations. The 100ms delay exhibits a failure after ~85 iterations. The 200ms delay passed all 100 iterations.
I don't know where to begin fixing this since it probably will involve threading (Qt) as well as semaphores in gl-render.cc.
|
Mon 23 Nov 2015 11:55:39 AM UTC, comment #2:
If I add "sleep (1)" before the delete (H) it does not crash Octave (checked with dev branch version on Win 7)
|
Mon 23 Nov 2015 05:41:00 AM UTC, comment #1:
This is related to bug #44875. In that bug, the warning is issued but it doesn't appear to crash Octave.
|
Mon 23 Nov 2015 05:39:14 AM UTC, original submission:
The attached file bad_plot.m, when run with the qt toolkit, causes Octave to crash. The file needs to be run twice for me to see the issue.
The backtrace under gdb isn't very informative, but here it is:
|