[cairo-bugs] [Bug 12995] New: Wireshark crashes with BadMatch
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Oct 29 11:48:14 PDT 2007
http://bugs.freedesktop.org/show_bug.cgi?id=12995
Summary: Wireshark crashes with BadMatch
Product: cairo
Version: 1.4.9
Platform: All
OS/Version: Mac OS X (All)
Status: NEW
Severity: normal
Priority: medium
Component: general
AssignedTo: cworth at cworth.org
ReportedBy: guy at alum.mit.edu
QAContact: cairo-bugs at cairographics.org
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 0x036ba78c in gdk_x_error ()
#1 0x038c59bc in _XError ()
#2 0x038c6fcc in _XReply ()
#3 0x038bc9d0 in XSync ()
#4 0x038bca74 in _XSyncFunction ()
#5 0x038878ec in XRenderCreatePicture ()
#6 0x037617f0 in _cairo_xlib_surface_ensure_dst_picture (surface=0x58323f0) at
cairo-xlib-surface.c:723
#7 0x03764cb0 in _cairo_xlib_surface_show_glyphs (abstract_dst=0x58323f0,
op=CAIRO_OPERATOR_OVER, src_pattern=0xbfffbcc8, glyphs=0x58326a0, num_glyphs=8,
scaled_font=Cannot access memory at address 0x0
) at cairo-xlib-surface.c:2832
#8 0x03748678 in _cairo_surface_show_glyphs (surface=0x58323f0,
op=CAIRO_OPERATOR_OVER, source=<value optimized out>, glyphs=0x5832a50,
num_glyphs=8, scaled_font=0x582bcc0) at cairo-surface.c:1830
#9 0x0373cde4 in _cairo_gstate_show_glyphs (gstate=0x5832730,
glyphs=0xbfffbf68, num_glyphs=8) at cairo-gstate.c:1449
#10 0x03738038 in cairo_show_glyphs (cr=0x5838c10, glyphs=<value optimized
out>, num_glyphs=<value optimized out>) at cairo.c:2555
#11 0x002ca8b0 in pango_cairo_renderer_draw_glyphs ()
#12 0x009bf940 in pango_renderer_draw_glyphs ()
#13 0x002cb0a8 in _pango_cairo_do_glyph_string ()
#14 0x009bf940 in pango_renderer_draw_glyphs ()
#15 0x009c0d18 in pango_renderer_draw_layout_line ()
#16 0x009c110c in pango_renderer_draw_layout ()
#17 0x0368a36c in gdk_draw_layout_with_colors ()
#18 0x00511030 in draw_row ()
#19 0x005112e4 in draw_rows ()
#20 0x0004b044 in packet_list_thaw () at packet_list.c:705
#21 0x0000d85c in cf_read (cf=0x10e090) at file.c:545
#22 0x00009970 in capture_input_closed (capture_opts=Cannot access memory at
address 0x0
) at capture.c:202
#23 0x0000b350 in sync_pipe_input_cb (source=5, user_data=0x11e1f0,
capture_opts=<value optimized out>) at capture_sync.c:649
#24 0x0003c9cc in pipe_input_cb (data=0x1227f0, source=5, condition=<value
optimized out>) at gui_utils.c:715
#25 0x03683db8 in gdk_io_invoke ()
#26 0x03a2b8a0 in g_main_context_dispatch ()
#27 0x03a2fbb4 in g_main_context_iterate ()
#28 0x03a2ffe4 in g_main_loop_run ()
#29 0x005c6a40 in gtk_main ()
#30 0x00046040 in main (argc=0, argv=0xbfffedc4) at main.c: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:
GTK+ 2.12.0
Pango 1.18.0
Cairo 1.4.10
ATK 1.18.0
GLib 2.14.0
on Mac OS X 10.5.
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
See also Pango bug 476409:
http://bugzilla.gnome.org/show_bug.cgi?id=476409
Wireshark bug 1953
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1953
which are for the same problem; I've also filed a bug against Leopard's X11.app
(Radar 5147896, but that's probably not accessible to people outside Apple), as
I don't know where the underlying problem is.
--
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.
More information about the cairo-bugs
mailing list