Not only leaving an application, but when GtkChamplainEmbed is destroyed, the application quits with the same error.

Seems like a Clutter issue: see http://bugzilla.openedhand.com/show_bug.cgi?id=1751

http://bugzilla.openedhand.com/show_bug.cgi?id=1750 has 2 patches that are supposed to address this.

(In reply to comment #3)
> http://bugzilla.openedhand.com/show_bug.cgi?id=1750 has 2 patches that are
> supposed to address this.
> 

They don't fix it here. Still getting the X error with the latest from the clutter-1.0 branch.

I confirm the error despite having both patches applied.

Can I get your video drivers? Ebassi thinks it could be my old Intel 2.4 drivers.  I'd be interested in getting your versions and compare.  If they differ, I'll bring it back to Emmanuele.

I am on nouveau git master (master-compat kernel module, no gallium dri).

Nvidia binary 185.18.31

Funny! After checking the driver version I noticed that my OpenGL libs where still set to mesa's software renderer (re-setup my system on monday). Switching to nvidia I now not only get the above message but also an XCB assertion:

The program '/home/felix/git/gnome/libchamplain/demos/.libs/launcher-gtk' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 979 error_code 3 request_code 10 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Locking assertion failure.  Backtrace:
#0 /usr/lib64/libxcb-xlib.so.0 [0x7fc30d657a7c]
#1 /usr/lib64/libxcb-xlib.so.0(xcb_xlib_lock+0x17) [0x7fc30d657be7]
#2 /usr/lib64/libX11.so.6 [0x7fc30d8a75c8]
#3 //usr/lib64/opengl/nvidia/lib/libGL.so.1 [0x7fc31070dd7b]
launcher-gtk: xcb_xlib.c:73: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.

Ok I isolated the precise issue.  It can be reproduced with pure Clutter code.  

If you put a GtkClutterEmbed inside a GtkViewport: Boom! remote the GtkViewport and you are back to normal :)

http://bugzilla.openedhand.com/show_bug.cgi?id=1751 has been updated with all the details.  I will keep this bug open in case the conclusion is to not embed GtkChamplainEmbed in a GtkViewport.

*** Bug 591831 has been marked as a duplicate of this bug. ***

*** Bug 592620 has been marked as a duplicate of this bug. ***

Considering it is quite late in the Gnome cycle, (and since Emmanuele Bassi doesn't really know whats going on here), I recommand to switch to using a work around: instead of putting the map in a GtkViewport (to get the bevel), you should be using a GtkFrame.

Lowering priority to normal.

Note for debuggers: this bug should also be reproduceable with a GtkGLExt, it'd be interesting to compare results.

JFYI: this ugly hack hides the crash, at least for me:


static void unrealize_clutter_fix_cb(GtkWidget *widget, gpointer data)
{
  GtkWidget *child = gtk_bin_get_child(GTK_BIN(widget));
  if (child) gtk_widget_unrealize(child);
}

[...]

g_signal_connect(G_OBJECT(viewport), "unrealize", G_CALLBACK(unrealize_clutter_fix_cb), NULL);

I haven't experienced anything like this lately and the corresponding clutter bug is marked as resolved, so marking as resolved too.