[cairo-bugs] [Bug 12995] Wireshark crashes with BadMatch

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=12995





------- Comment #1 from guy at alum.mit.edu  2007-10-29 22:37 PST -------
Owen Taylor noted in the Pango bug:

    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())

and I subsequently noted that

    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.

and later, in response to Owen's suggestion, hacked up
gdk_x11_ref_cairo_surface() to print the information he mentioned:

    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.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.