GNOME Bugzilla – Bug 162892
gataxx crash on close
Last modified: 2012-01-31 23:25:29 UTC
To trigger this, I click on the board or even the menubar, then immediately after, click on the close button on the window. (It was an accident, I meant to hit the X the first time around...) There's a race condition there, and I usually can't trigger the bug. I get it once out of about a dozen tries if I'm lucky. The 'GLib-GObject-WARNING' below shows up in the console. ------------- (gdb) run Starting program: /usr/bin/gataxx [Thread debugging using libthread_db enabled] [New Thread -151111456 (LWP 27808)] Detaching after fork from child process 27828. (gataxx:27808): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid >' in cast to `GtkWidget' Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -151111456 (LWP 27808)] 0x0804d3d8 in gtk_gridboard_draw_pixmap (gridboard=0x82a5bb0, which=0, x=0, y=0) at gtkgridboard.c:275 275 gdk_draw_drawable (widget->window, (gdb) thread apply all bt
+ Trace 54128
Thread 1 (Thread -151111456 (LWP 27808))
Nevermind about the first part of the bug, no clicking is needed. Just close the window...
Created attachment 35461 [details] [review] Raise priority of the animation timeout. Well, it's definitely a case of the animation timeout triggering after gtk_main_quit(). I think I see why and how it's happening, and I remember the gnobots bug that was just like this. I tried removing the source for the animation timeout before calling gtk_main_quit(), but still managed to run into the crash... perhaps it was removed only from future iterations of the loop...? I'm not at all sure. Taking the easy way out, this patch just makes sure that the animation timeout would happen before the quit callback if they happen during the same iteration of the main loop.
Comment on attachment 35461 [details] [review] Raise priority of the animation timeout. That patch can't possibly be the right thing to do. Even if it does work. I'm currently trying to get the last features into same-gnome before the feature freeze. Next week will be my big week for clearing bugs.
I'll keep looking at it too... Fixing it the usual right way led to a crash, though only once, during the second try out of about a hundred or so... It could have been a different crash, or just something else completely goofing up.
Created attachment 35522 [details] The usual fix (AFAIK), though it doesn't work. For completeness, I tried the patch above, though it doesn't stop this bug from coming up. Posting here after finding Bug #163088, then discovering that it wasn't unrelated. :)
Make sure animation is enabled. Extra info: I've also tested this out on gnome-games-2.8.2 a stock FC3 machine (glib & gtk+ 2.4), the crash was also there. ----- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -151106816 (LWP 21834)] 0x001bb66b in _int_malloc () from /lib/tls/libc.so.6 (gdb) thread apply all bt
+ Trace 54239
Thread 1 (Thread -151106816 (LWP 21834))
So far all I have managed to determine is that you are correct. The timeout is called after gtk_main_quit has executed and explicitly killing the timeout (as in your patch) doesn't stop it happening. Really strange. Setting PIXMAP_FLIP_DELAY to 1 triggers it everytime.
Further notes with no resolution. Running a test program gives the correct result. If I remove the source of course. The way the glib main loop code seems to be set up is that it runs a set of checks for events and then processes them before checking the see if the loop should exit. The timeout and the GTK stuff are separate sources so they can both produce events which then get processed before the enxt iteration of the main loop. The reason that raising the priority fixes this is that it guarantees that the timeout happens before the delete_event. This model of what happens says that removing the source should fix it. My test code says the same thing. The gataxx code doesn't behave this way though.
Created attachment 35943 [details] The test code which actually works. Compile with gcc `pkg-config --cflags --libs libgnomeui-2.0` -o test test.c Run the program from the console and close the window. If it is well behaved the text on stdout should end with "Quit". If not there will be a "Tick" after the "Quit".
I have committed the "correct" patch to CVS for the 2.9.5 release. It doesn't fix it, but it does need to be there.
Fixed properly now. There were two issues. Firstly the patch is wrong. timeoutid should not be declared guint in a header file, this results in *two* definitions of timeoutid and undefined behaviour (although gcc often does what is wanted). The correct thing is to declare it extern guint in the header and guint in one of the files. Secondly the animation was being set up twice. Once at initialisation and once when the prefs are read. This means two timeouts were created, only one was removed. I have changed the code to ignore the gtk_gridboard_set_animate call if animation is already going.
*** Bug 172829 has been marked as a duplicate of this bug. ***
This bug is being reassigned to the "general" component so we can close the gataxx bugzilla component. Apologies for the mass email!