Thanks.

And yes, these event driven bugs are pretty difficult to fix.  Dan is right that we probably need a different approach to dealing with the way the plotting widget accesses interpreter data.  As it is now, it seems possible to ask for that data at random times when the graphics objects may not be in a state that is suitable for access.

Closing this report anyway since the immediate problem appears to be fixed and the threading issues are well-known beyond this bug report.

I got this error to happen once, but it is really hard to reproduce.  I ran the code in a for loop several hundred times but it only ever happened once.  Since I can't reproduce it reliably I just can't help.

I have to say it's a very frustrating one as it appears randomly (and so before and after Dan's patch).
It seems that it is more likely to happen if you had time to see the red panel before it is deleted (unfortunately adding a pause does not help).
I'll try to build a longer example where the error appears with more certainty but even with this example, try a few more times, adding a few return keys in between attempts and a 'clear all'.

I've been observing an error  "base_graphics_object::get_properties: invalid graphics object" for a while in a large-ish GUI, when clearing a figure of all its objects, and this with 100% reproducibility. I've tried to trim down a workable example, see below, but sadly, now, the issue is harder to reproduce and the error appears more randomly. Try to copy-paste the following at the Octave prompt, including the carriage return for the last line.

F = figure('MenuBar','none');
uimenu(F,'Label','Menu');
uipanel('Parent',F,...
        'Position',[0.1 0.1 0.8 0.8],...
        'BackgroundColor',[0.5 0 0]);

H = findall(allchild(F),'flat');

delete(H);

You should see this from time to time:

>> error: base_graphics_object::get_properties: invalid graphics object