GNOME Bugzilla – Bug 309512
crash when showing color-circle on color selector
Last modified: 2011-02-04 16:18:46 UTC
Steps to reproduce: Open any color-selector with circle. Stack trace: Gdk-ERROR **: The program 'gtk-demo' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 48068 error_code 8 request_code 72 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.) aborting... Program received signal SIGTRAP, Trace/breakpoint trap. 0xb7a9bc5c in g_logv () from /usr/lib/libglib-2.0.so.0 (gdb) bt
+ Trace 61589
Other information: Self compiled: gtk-2.7.1, glib-2.7.1, pango-1.9.0, cairo-0.5.1, clearlooks-0.6.1; From packages: Xorg-6.8.2, gcc-3.4.3 from Slackware-current.
Please attach the output of 'xdpyinfo' as an attachment.
Created attachment 48678 [details] output of xdpyinfo
Running with --sync would give a much more useful backtrace.
It was run with --sync; I did: $ gdb gtk-demo (gdb) run "--sync" (Click Color Selector, click Change the above color, it crashed) (gdb) bt
Does the problem go away if you turn off composite in your server? (it looks like you have it explicitely turned on in your xorg.conf)
Can't reproduce with this xorg 6.8.1.901 X server after turning Composite on
And not with xorg 6.8.2 either
Turning Composite on and off has no effect, it still crashes the same way. Some more, maybe important information: it's Matrox G550 driven by mga driver. Should I recompiled something with more debugging information?
Any chance you could try to figure out what is wrong with the XPutImage parameters ? E.g is the image contained within the pixmap dimensions ?
XPutImage seems to be part of Xorg (libX11.so.6). Recompiling whole X package with debugging enabled is rather out of question, sorry. What else can I do?
the XPutImage call is in cairo, so having debug info for cairo may be enough to see the parameters of the call. Or you could insert a printf in cairo before the call.
The only documented reason that PutImage should BadMatch for a ZPixmap is a depth mismatch. The call chain here is presumably (guessing in absence of useful debug info) _draw_image_surface _cairo_xlib_surface_clone_similar _cairo_surface_clone_similar _cairo_pattern_acquire_surface_for_surface [...] cairo_stroke paint_ring The image surface is created with: source = cairo_image_surface_create_for_data ((char *)buf, CAIRO_FORMAT_RGB24, width, height, 4 * width); This should result in an image surface with image->depth == 24. (I think there was a bug fix here as of: 2005-03-11 Owen Taylor <otaylor@redhat.com> * src/icformat.c (pixman_format_init): Set format->depth correctly instead of just using the bpp. Hmm, could you have an old version of libpixman?) The destination surface should be a depth 24 pixmap. So, investigation would be finding out which one of these assumptions is wrong.
Parameters passed to XPutImage from printf(): dpy: 80756B8; drawable: 3800417; gc: 82975E0; ximage: 8297580, dst_x: 0, dst_y: 0, width: 178, height: 178 Backtrace:
+ Trace 61600
BTW, libpixman-0.1.4
Mr. Taylor, you were right. After upgrading to libpixman-0.1.5 problem went away.