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 476409 - Wireshark crashes with BadMatch
Wireshark crashes with BadMatch
Status: RESOLVED NOTGNOME
Product: pango
Classification: Platform
Component: general
1.18.x
Other Mac OS
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2007-09-13 02:49 UTC by Guy Harris
Modified: 2007-10-30 12:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Guy Harris 2007-09-13 02:49:15 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:

  • #0 gdk_x_error
  • #1 _XError
  • #2 _XReply
  • #3 XSync
  • #4 _XSyncFunction
  • #5 XRenderCreatePicture
  • #6 _cairo_xlib_surface_ensure_dst_picture
    at cairo-xlib-surface.c line 723
  • #7 _cairo_xlib_surface_show_glyphs
    at cairo-xlib-surface.c line 2832
  • #8 _cairo_surface_show_glyphs
    at cairo-surface.c line 1830
  • #9 _cairo_gstate_show_glyphs
    at cairo-gstate.c line 1449
  • #10 cairo_show_glyphs
    at cairo.c line 2555
  • #11 pango_cairo_renderer_draw_glyphs
  • #12 pango_renderer_draw_glyphs
  • #13 _pango_cairo_do_glyph_string
  • #14 pango_renderer_draw_glyphs
  • #15 pango_renderer_draw_layout_line
  • #16 pango_renderer_draw_layout
  • #17 gdk_draw_layout_with_colors
  • #18 draw_row
  • #19 draw_rows
  • #20 packet_list_thaw
    at packet_list.c line 705
  • #21 cf_read
    at file.c line 545
  • #22 capture_input_closed
    at capture.c line 202
  • #23 sync_pipe_input_cb
    at capture_sync.c line 649
  • #24 pipe_input_cb
    at gui_utils.c line 715
  • #25 gdk_io_invoke
  • #26 g_main_context_dispatch
  • #27 g_main_context_iterate
  • #28 g_main_loop_run
  • #29 gtk_main
  • #30 main
    at main.c line 3036

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}.
Comment 1 Guy Harris 2007-09-13 03:03:18 UTC
(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
Comment 2 Behdad Esfahbod 2007-09-14 20:15:40 UTC
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
Comment 3 Guy Harris 2007-09-14 20:28:25 UTC
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.
Comment 4 Behdad Esfahbod 2007-09-14 20:42:01 UTC
(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.
Comment 5 Guy Harris 2007-09-15 01:06:26 UTC
Cairo 1.4.10 doesn't fix the problem.  Now that 2.12 is out, I'll see if that works.
Comment 6 Guy Harris 2007-09-18 00:52:48 UTC
Still fails with:

GTK+ 2.12.0
Pango 1.18.0
Cairo 1.4.10
ATK 1.18.0
GLib 2.14.0
Comment 7 Guy Harris 2007-10-29 18:56:29 UTC
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.
Comment 8 Owen Taylor 2007-10-29 19:10:31 UTC
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())
Comment 9 Guy Harris 2007-10-29 20:24:28 UTC
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?
Comment 10 Guy Harris 2007-10-30 02:37:11 UTC
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.
Comment 11 Guy Harris 2007-10-30 05:43:15 UTC
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)?
Comment 12 Owen Taylor 2007-10-30 12:14:11 UTC
If the trail pointing to cairo or Xlib goes cold, this can be reopened and
reassigned to GTK+.