GTK bug?

[hgm]

They say you should never use the word bug unless you are referring to your own code. But in the GUI code I was writing for ShogiVar (mostly adapted from the XBoard front-end) I really stumpled on extremely weird behavior:

When I pop down a transient dialog, I destroy it afterwards with gtk_widget_destroy(). This always worked fine in XBoard. But in ShogiVar I was using it for a window that contained a menu bar, and the popdown was in response to clicking a menu item in that bar.

Turns out that this causes events to occur (in particular expose events) in sub-widgets of the dialog that is destroyed, and which are thus destroyed themselves. This already triggers a number of GTK asserts in the system itself (complaining that things are not widgets), and eventually calls my user handler, which segfaults the program by drawing in a nonvalid widget.

I could work around it by first doing a normal popdown through gtk_widget_hide(), and schedule the gtk_widget_destoy (and everything that should follow it) through a timer event with a delay of 500 ms. (100 ms was not enough!)

I would think that by definition this must count as a GTK bug, right? It should never generate an event passing an invalid widget with it.

[stegemma]

I don't know about GTK but, in C++ Builder VCL, sometimes you have to test the state of a component, to know if it is destroying, to avoid errors similar to those you found.

Maybe there's a destroying state flag even in GTK components?

[syzygy]

On windows, using multiple threads?
http://www.gtkforums.com/viewtopic.php?p=197534#p197534

Probably not, but who knows.

[hgm]

No, it is Linux and single thread.

And yes, I could test if the widget that is passed to the handler to see if it is a valid widget, and just return without touching it if it isn't, which would probably avod the segfault. It would still spit out the error messages about failing asserts from within GTK itself, though, in the console.