After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 590692 - X error when using GtkChamplainEmbed
X error when using GtkChamplainEmbed
Status: RESOLVED OBSOLETE
Product: libchamplain
Classification: Core
Component: gtk-embed
0.3.x
Other Linux
: Normal normal
: 0.4
Assigned To: libchamplain-maint
libchamplain-maint
: 591831 592620 (view as bug list)
Depends on:
Blocks: 588397 591543
 
 
Reported: 2009-08-04 02:14 UTC by Pierre-Luc Beaudoin
Modified: 2010-05-11 20:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Pierre-Luc Beaudoin 2009-08-04 02:14:50 UTC
<Leaving an application using GtkChamplainEmbed results in 

The program '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 14454 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.)
Comment 1 Pierre-Luc Beaudoin 2009-08-04 02:52:24 UTC
Not only leaving an application, but when GtkChamplainEmbed is destroyed, the application quits with the same error.
Comment 2 Pierre-Luc Beaudoin 2009-08-05 19:20:31 UTC
Seems like a Clutter issue: see http://bugzilla.openedhand.com/show_bug.cgi?id=1751
Comment 3 Patryk Zawadzki 2009-08-12 09:22:57 UTC
http://bugzilla.openedhand.com/show_bug.cgi?id=1750 has 2 patches that are supposed to address this.
Comment 4 Felix Riemann 2009-08-12 13:41:08 UTC
(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.
Comment 5 Patryk Zawadzki 2009-08-12 13:55:40 UTC
I confirm the error despite having both patches applied.
Comment 6 Pierre-Luc Beaudoin 2009-08-12 14:16:40 UTC
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.
Comment 7 Patryk Zawadzki 2009-08-12 14:23:36 UTC
I am on nouveau git master (master-compat kernel module, no gallium dri).
Comment 8 Felix Riemann 2009-08-12 14:39:03 UTC
Nvidia binary 185.18.31
Comment 9 Felix Riemann 2009-08-12 15:59:01 UTC
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.
Comment 10 Pierre-Luc Beaudoin 2009-08-12 16:17:57 UTC
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 :)
Comment 11 Pierre-Luc Beaudoin 2009-08-12 16:31:37 UTC
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.
Comment 12 Pierre-Luc Beaudoin 2009-08-17 17:19:14 UTC
*** Bug 591831 has been marked as a duplicate of this bug. ***
Comment 13 Pierre-Luc Beaudoin 2009-08-22 03:13:25 UTC
*** Bug 592620 has been marked as a duplicate of this bug. ***
Comment 14 Pierre-Luc Beaudoin 2009-08-24 13:59:53 UTC
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.
Comment 15 Vladimir Nadvornik 2009-10-10 14:48:01 UTC
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);
Comment 16 Jiri Techet 2010-05-11 20:34:17 UTC
I haven't experienced anything like this lately and the corresponding clutter bug is marked as resolved, so marking as resolved too.