GNOME Bugzilla – Bug 476409
Wireshark crashes with BadMatch
Last modified: 2007-10-30 12:14:11 UTC
When running Wireshark with --sync under GDB, I get a BadMatch error when I try to capture and stop the capture. The stack trace is:
+ Trace 162514
xdpyinfo says name of display: /tmp/launch-ZLB0AT/:0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 70200000 X.Org version: 7.2.0 maximum request size: 16777212 bytes motion buffer size: 0 bitmap unit, bit order, padding: 32, MSBFirst, 32 image byte order: MSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: PointerRoot number of extensions: 28 Apple-DRI Apple-WM BIG-REQUESTS DAMAGE DEC-XTRAP DOUBLE-BUFFER DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XAccessControlExtension XC-APPGROUP XC-MISC XFIXES XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: print screen: no dimensions: 1920x1179 pixels (650x399 millimeters) resolution: 75x75 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x3f depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x21 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 32x32 current input event mask: 0x0 number of visuals: 4 default visual id: 0x23 visual: visual id: 0x23 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x24 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x25 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x26 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits A version of the X server with some debugging printouts added prints ProcRenderCreatePicture: BadMatch due to pformat->depth (24) != pDrawable->depth (32) which means that the failure was in static int ProcRenderCreatePicture (ClientPtr client) { PicturePtr pPicture; DrawablePtr pDrawable; PictFormatPtr pFormat; int len; int error; REQUEST(xRenderCreatePictureReq); REQUEST_AT_LEAST_SIZE(xRenderCreatePictureReq); LEGAL_NEW_RESOURCE(stuff->pid, client); SECURITY_VERIFY_DRAWABLE(pDrawable, stuff->drawable, client, SecurityWriteAccess); pFormat = (PictFormatPtr) SecurityLookupIDByType (client, stuff->format, PictFormatType, SecurityReadAccess); if (!pFormat) { client->errorValue = stuff->format; return RenderErrBase + BadPictFormat; } if (pFormat->depth != pDrawable->depth) return BadMatch; <-this is the failure If I configure X11.app to have "thousands" rather than "millions" of colors - i.e., to offer only 16 bits of color rather than 24 bits of color - the problem goes away. (Is the Drawable 24 bits of color + 8 bits of alpha with "millions" of colors, and does it become 16 bits of color + 8 bits of alpha with only "thousands" of colors, so that the depth is 24 bits?) This is with: GLib 2.12.13 ATK 1.12.1 Cairo 1.2.6 Pango 1.16.4 GTK+ 2.10.14 on Mac OS X 10.{not yet available to the general public}.
(BTW, we've already indicated that Leopard will have X.org: http://lists.apple.com/archives/x11-users/2007/Jun/msg00026.html so that's not a Deep Dark Secret.) In thousands-of-colors mode, xdpyinfo prints name of display: /tmp/launch-ZLB0AT/:0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 70200000 X.Org version: 7.2.0 maximum request size: 16777212 bytes motion buffer size: 0 bitmap unit, bit order, padding: 32, MSBFirst, 32 image byte order: MSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: None number of extensions: 28 Apple-DRI Apple-WM BIG-REQUESTS DAMAGE DEC-XTRAP DOUBLE-BUFFER DPMS Extended-Visual-Information GLX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XAccessControlExtension XC-APPGROUP XC-MISC XFIXES XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: print screen: no dimensions: 1920x1179 pixels (650x399 millimeters) resolution: 75x75 dots per inch depths (7): 15, 1, 4, 8, 16, 24, 32 root window id: 0x3f depth of root window: 15 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x21 default number of colormap cells: 32 preallocated pixels: black 0, white 32767 options: backing-store NO, save-unders NO largest cursor: 32x32 current input event mask: 0x1a0000 StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask number of visuals: 4 default visual id: 0x23 visual: visual id: 0x23 class: TrueColor depth: 15 planes available colormap entries: 32 per subfield red, green, blue masks: 0x7c00, 0x3e0, 0x1f significant bits in color specification: 5 bits visual: visual id: 0x24 class: TrueColor depth: 15 planes available colormap entries: 32 per subfield red, green, blue masks: 0x7c00, 0x3e0, 0x1f significant bits in color specification: 5 bits visual: visual id: 0x25 class: TrueColor depth: 15 planes available colormap entries: 32 per subfield red, green, blue masks: 0x7c00, 0x3e0, 0x1f significant bits in color specification: 5 bits visual: visual id: 0x26 class: TrueColor depth: 15 planes available colormap entries: 32 per subfield red, green, blue masks: 0x7c00, 0x3e0, 0x1f significant bits in color specification: 5 bits
Cairo 1.2.6 is too old. Please try with cairo 1.4.10 and reopen if still happens. Also helps if you try it with pango 1.18.x
Mersi! I'll give that a try. Cairo 1.2.6 is the version in the dependencies directory on the gtk.org FTP site: ftp://ftp.gtk.org/pub/gtk/v2.10/dependencies If 1.2.6 is too old, the maintainers of ftp.gtk.org might want to update the version there.
(In reply to comment #3) > Mersi! I'll give that a try. > > Cairo 1.2.6 is the version in the dependencies directory on the gtk.org FTP > site: > > ftp://ftp.gtk.org/pub/gtk/v2.10/dependencies > > If 1.2.6 is too old, the maintainers of ftp.gtk.org might want to update the > version there. Gtk+ 2.10 is too old too :). When Gtk+ 2.10 was released last year, cairo 1.2 was current... Version requirements are not topped in bugfix releases, that's why the latest Gtk+ 2.10 release doesn't require cairo 1.4.
Cairo 1.4.10 doesn't fix the problem. Now that 2.12 is out, I'll see if that works.
Still fails with: GTK+ 2.12.0 Pango 1.18.0 Cairo 1.4.10 ATK 1.18.0 GLib 2.14.0
I've filed a bug against Cairo as well, in case this is a Cairo problem - or in case the Cairo people can suggest what the {Wireshark, Pango, GTK+, X11.app} developers should be looking at: https://bugs.freedesktop.org/show_bug.cgi?id=12995 and somebody's filed a bug against Wireshark for this: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1953 There's also a bug in the Apple bug database against X11.app - 5147896 - although I don't know whether non-Apple people can see it.
This is almost certainly not a Pango issue. Hard to say what is going on without knowing what wireshark is doing ... it appears that the cairo surface that it's using got created improperly for the actual drawing it's drawing to. I'm not quite sure how that could happen, since I think GTK+ always should be validating the depth to match that of the drawable. It's conceivable that your libX11 is doing something unusual. The code that creates the cairo surface is in GTK+ gdk_x11_ref_cairo_surface() Check: A) the depth of the visual B) the depth that GTK+ thinks the drawable (most likely a pixmap) has C) the actual depth of the drawable (use XGetGeometry())
It was a bit buried in the middle of the initial bug report, so it's easy to miss, but I hacked up the X server to report the precise problem; it printed ProcRenderCreatePicture: BadMatch due to pformat->depth (24) != pDrawable->depth (32) which means that the failure was in static int ProcRenderCreatePicture (ClientPtr client) { ... if (pFormat->depth != pDrawable->depth) return BadMatch; <-this is the failure So the X server seems to think the drawable has a depth of 32. According to xdpyinfo, the visuals were number of visuals: 4 default visual id: 0x23 visual: visual id: 0x23 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x24 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x25 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x26 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits so they all appear to be 24-bit. So should I hack up gdk_x11_ref_cairo_surface() to print the three pieces of information you mention?
The following code, stuck after the gdk_drawable_get_visual() call in gdk_x11_ref_cairo_surface(), repeatedly swears on a stack of Bibles that the visual and the drawable are both of depth 24, as is the depth as reported by XGetGeometry(): if (logfile != NULL) { if (visual != NULL) fprintf(logfile, "Visual: depth %d\n", visual->depth); fprintf(logfile, "Drawable: depth %d\n", gdk_drawable_get_depth(drawable)); if (XGetGeometry(GDK_SCREEN_XDISPLAY (impl->screen), impl->xid, &root, &x, &y, &xwidth, &xheight, &border_width, &depth)) fprintf(logfile, "Drawable: X11 depth %u\n", depth); else fprintf(logfile, "XGetGeometry failed\n"); } ("logfile" was opened earlier). From a quick look at _cairo_xlib_surface_ensure_dst_picture() in Cairo 1.4.10's cairo-xlib-surface.c, and from the failure mode on the server (24-bit drawable, 32-bit format), it appears that surface->drawable would be 24-bit and surface->xrender_format would be 32-bit. That would agree with the debug code's insistence that the visual and drawable are 24-bit.
I've copied Owen's and my recent comments to the Cairo bug at http://bugs.freedesktop.org/show_bug.cgi?id=12995 Owen, you're right, this probably isn't Pango; should this be closed as NOTGNOME or something such as that, and discussion continued, for now, on the Cairo bug (at least until it's determined either to be the fault of Leopard's X11 server, GTK+/GDK, or Wireshark)?
If the trail pointing to cairo or Xlib goes cold, this can be reopened and reassigned to GTK+.