I've noticed a consistent crash of a unicode gtk/wxGtk application in cairo. The backtrace appears simillar to bug 4505, however the application works fine until , what I'm guessing is an unknown unicode string needs to get rendered, when this crash occurs. I'm running this application within XVnc (tightvnc 1.3_alpha7) and the server should be running in 16-bit color (and not 8-bit pseudocolor as mentioned in bug 4505), but it could be related. Thanks. The other related libs are: gtk+-2.8.10 pango-1.10.2 glib-2.8.5 freetype-2.1.9 Here's what's xdpyinfo reports: version number: 11.0 vendor string: AT&T Laboratories Cambridge vendor release number: 3332 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x3400009, revert to PointerRoot number of extensions: 7 BIG-REQUESTS MIT-SHM MIT-SUNDRY-NONSTANDARD SHAPE SYNC XC-MISC XTEST default screen number: 0 number of screens: 1 screen #0: dimensions: 1280x1024 pixels (433x347 millimeters) resolution: 75x75 dots per inch depths (1): 16 root window id: 0x25 depth of root window: 16 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x21 default number of colormap cells: 64 preallocated pixels: black 0, white 65535 options: backing-store YES, save-unders YES largest cursor: 1280x1024 current input event mask: 0xfa4031 KeyPressMask EnterWindowMask LeaveWindowMask KeymapStateMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals: 1 default visual id: 0x22 visual: visual id: 0x22 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 8 bits And here is the backtrace: -------------------------------------------- #0 0xb709a232 in _cairo_ft_scaled_font_show_glyphs (abstract_font=0x970e2f0, operator=CAIRO_OPERATOR_CLEAR, pattern=0xbf9a8ee0, surface=0x96f04f0, source_x=0, source_y=0, dest_x=112, dest_y=9, width=138, height=13, glyphs=0x96864a8, num_glyphs=9) at cairo-ft-font.c:1988 #1 0xb708555f in _cairo_scaled_font_show_glyphs (scaled_font=0x970e2f0, operator=CAIRO_OPERATOR_OVER, pattern=0xbf9a8ee0, surface=0x96f04f0, source_x=112, source_y=9, dest_x=112, dest_y=9, width=138, height=13, glyphs=0x96864a8, num_glyphs=9) at cairo-font.c:940 #2 0xb7088d5d in _cairo_gstate_show_glyphs_draw_func (closure=0xbf9a8ec0, operator=CAIRO_OPERATOR_CLEAR, src=0xbf9a8ee0, dst=0x0, dst_x=0, dst_y=0, extents=0xbf9a8eb8) at cairo-gstate.c:2053 #3 0xb70876f8 in _cairo_gstate_clip_and_composite (clip=0x96eff6c, operator=CAIRO_OPERATOR_OVER, src=0xbf9a8ee0, draw_func=0xb7088c80 <_cairo_gstate_show_glyphs_draw_func>, draw_closure=0xbf9a8ec0, dst=0x96f04f0, extents=0xbf9a8eb8) at cairo-gstate.c:1094 #4 0xb7088f8e in _cairo_gstate_show_glyphs (gstate=0x96efee8, glyphs=0xbf9a8fc0, num_glyphs=9) at cairo-gstate.c:2131 #5 0xb7082073 in cairo_show_glyphs (cr=0x97c02a8, glyphs=0x96eed78, num_glyphs=0) at cairo.c:2158 #6 0xb70bf312 in pango_cairo_renderer_get_type () from /usr/lib/libpangocairo-1.0.so.0 #7 0xb730d279 in pango_renderer_draw_glyphs () from /usr/lib/libpango-1.0.so.0 #8 0xb70bf807 in pango_cairo_show_glyph_string () from /usr/lib/libpangocairo-1.0.so.0 #9 0xb73708b0 in gdk_pango_renderer_get_type () from /usr/lib/libgdk-x11-2.0.so.0 #10 0xb730d279 in pango_renderer_draw_glyphs () from /usr/lib/libpango-1.0.so.0 #11 0xb730d140 in pango_renderer_draw_layout_line () from /usr/lib/libpango-1.0.so.0 #12 0xb730c84b in pango_renderer_draw_layout () from /usr/lib/libpango-1.0.so.0 #13 0xb7371f45 in gdk_draw_layout_with_colors () from /usr/lib/libgdk-x11-2.0.so.0 #14 0xb7372151 in gdk_draw_layout () from /usr/lib/libgdk-x11-2.0.so.0
I can easily reproduce a similar problem with gtk+-2.8.3/examples/paned/paned which shows up all yellow on X-Win32 in my environment. Some of my co-workers see teal. Why is this relavent here? Because we also have problems with Exceed and viewing the Linux on a Solaris and have seen the core dump when experimenting with Pseudo Color to try to workaround the situation. My guess is that wrong color issues are related to this seg fault. See bug 5212. The color problems we have seen from Cairo affect gtk+, wxwidgets, and QT in many situations when the users try to make use of the Cairo dependent in a common X-windows use model of running on one machine and viewing on another. I would strongly plead for this bug to be fixed as well as bug 5212.
The segmentation issue has been fixed so this becomes a simple dup of 5212 (which I haven't yet worked out if has been fixed...) *** This bug has been marked as a duplicate of bug 5212 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.