on Solaris 2.8 gtk applications crash with a SEGMENTATION FAULT. the problem seems to be located inside file fbcompose.c ($XdotOrg: xc/programs/Xserver/fb/fbcompose.c,v 1.5 2005/01/13 20:49:21 sandmann Exp $) inside method "void fbFetch(PicturePtr pict, int x, int y, int width, CARD32 *buffer)" the pointer "fetch" ("fetchProc fetch = fetchProcForPicture(pict);") is not checked againt zero value and at line 2673 the call: "fetch(bits, x, width, buffer, indexed);" causes a segmentation fault. software config: cairo-1.0.0 gtk+-2.8.3 pango-1.10.0 renderext-0.9 libXrender-0.9.0 backtrace: 76 Program received signal SIGSEGV, Segmentation fault. 77 0x00000000 in ?? () 78 #0 0x00000000 in ?? () 79 #1 0xfe9de844 in fbFetch (pict=0x14d840, x=0, y=1366080, width=0, buffer=0x35) 80 at fbcompose.c:2673 81 #2 0xfe9e0c7c in fbCompositeRect (data=0xffbe44f8, scanline_buffer=0xffbe4518) 82 at fbcompose.c:3565 83 #3 0xfe9e1428 in pixman_compositeGeneral (op=4290659576, pSrc=0x14d930, 84 pMask=0x14d520, pDst=0x35, xSrc=152, ySrc=12, xMask=0, yMask=0, xDst=0, 85 yDst=0, width=53, height=9) at fbcompose.c:3677 86 #4 0xfe9b5958 in _cairo_image_surface_composite ( 87 operator=CAIRO_OPERATOR_OVER, src_pattern=0xffbeab88, 88 mask_pattern=0xffbea778, abstract_dst=0x14d8b8, src_x=152, src_y=12, 89 mask_x=0, mask_y=0, dst_x=0, dst_y=0, width=53, height=9) 90 at cairo-image-surface.c:595 91 #5 0xfe9baee4 in _fallback_composite (operator=CAIRO_OPERATOR_OVER, 92 src=0xffbeab88, mask=0xffbea778, dst=0x0, src_x=152, src_y=12, mask_x=0, 93 mask_y=0, dst_x=152, dst_y=12, width=53, height=9) at cairo-surface.c:800 94 #6 0xfe9c43c8 in _cairo_ft_scaled_font_show_glyphs (abstract_font=0x18, 95 operator=CAIRO_OPERATOR_OVER, pattern=0xffbeab88, surface=0x149ce8, 96 source_x=152, source_y=12, dest_x=152, dest_y=12, width=53, height=9, 97 glyphs=0x14ce88, num_glyphs=7) at cairo-ft-font.c:2048 98 #7 0xfe9b0fa4 in _cairo_scaled_font_show_glyphs (scaled_font=0xdc200, 99 operator=CAIRO_OPERATOR_OVER, pattern=0xffbeab88, surface=0x149ce8, 100 source_x=152, source_y=12, dest_x=152, dest_y=12, width=53, height=9, 101 glyphs=0x14ce88, num_glyphs=7) at cairo-font.c:929 102 #8 0xfe9b422c in _cairo_gstate_show_glyphs_draw_func (closure=0xffbeab60, 103 operator=CAIRO_OPERATOR_OVER, src=0xffbeab88, dst=0x149ce8, dst_x=0, 104 dst_y=0, extents=0xffbeab70) at cairo-gstate.c:2053 105 #9 0xfe9b2f88 in _cairo_gstate_clip_and_composite (clip=0x14cdb0, 106 operator=CAIRO_OPERATOR_OVER, src=0xffbeab88, 107 draw_func=0xfe9b4144 <_cairo_gstate_show_glyphs_draw_func>, 108 draw_closure=0xffbeab60, dst=0x149ce8, extents=0xffbeab70) 109 at cairo-gstate.c:1094 110 #10 0xfe9b43ac in _cairo_gstate_show_glyphs (gstate=0x14cd20, 111 glyphs=0xffbeacf8, num_glyphs=7) at cairo-gstate.c:2131 112 #11 0xfe9add80 in cairo_show_glyphs (cr=0xdbbc0, glyphs=0xffbeacf8, 113 num_glyphs=7) at cairo.c:2158 114 #12 0xff2c617c in pango_cairo_renderer_get_type () 115 from /local/dsipos/app/lib/libpangocairo-1.0.so.0 ...
----------------------------------------------------------------------------- I'm having the same problem under Solaris 8. However, I've got two graphic cards and two displays on a Sun Ultra-60. Display :0 is a Creator 3D card and display :1 is an Elite-3d. The problem only occurs on the Creator-3D card (the code isn't called when displaying on the Elite-3D). X is running with 24 bit planes. I've been working with cairo-1.0.0 but cairo-1.0.2 has the same problem. Some checking into the code shows that whenever fetchProcForPicture() is called, the value of pict->format_code is 0x08010000 (which is not listed in the switch() statement). As a result, 0 gets returned. gtk+-2.8.6 cairo-1.0.0 pango-1.10.1 render-0.8 xrender-0.8.3 gcc-4.0.1 Vic Hoover -----------------------------------------------------------------------------
I'm also having this same problem under Solaris 9. In our environment, the segmentation fault seems to occur only when running with 8 planes (with three different graphics cards: XVR-1000, Expert3D-Lite and single-buffered FFB1 - I think this last one is built into the motherboard). When running with 24 planes, the segmentation fault does not occur and gtk-demo seems to run fine. Software configuration: gtk+-2.8.8 cairo-1.0.2 pango-1.10.1 render-0.9 xrender-0.9.0 gcc-3.2.2
(In reply to comment #1) > ----------------------------------------------------------------------------- > I'm having the same problem under Solaris 8. However, I've got two graphic > cards and two displays on a Sun Ultra-60. Display :0 is a Creator 3D card > and display :1 is an Elite-3d. The problem only occurs on the Creator-3D card > (the code isn't called when displaying on the Elite-3D). X is running with > 24 bit planes. I've been working with cairo-1.0.0 but cairo-1.0.2 has the > same problem. > > Some checking into the code shows that whenever fetchProcForPicture() is called, > the value of pict->format_code is 0x08010000 (which is not listed in the switch() > statement). As a result, 0 gets returned. > > gtk+-2.8.6 > cairo-1.0.0 > pango-1.10.1 > render-0.8 > xrender-0.8.3 > gcc-4.0.1 > > Vic Hoover > ----------------------------------------------------------------------------- > I just double checked my setup. The Elite3D card was configured as 24 planes but the Creator3D (which was having the problem) was indeed configured as 8 planes. I'll get that changed and retest.
This bug also presents itself on OpenBSD/macppc. I have tracked down where the bad format_code is created, however I don't know the proper fix for this. The bad format_code is created in _get_image_surface() in cairo-xlib-surface.c around line 532 when surface->visual is not 0. I see the masks struct filled in with bpp = 8 alpha_mask = 0 red_mask = 0 green_mask = 0 blue_mask =0. The call to _CAIRO_MASK_FORMAT call returns False, then _cairo_image_surface_create_with_masks is called which in turn calls _cairo_pixman_format_create_masks which creates the format_code of 0x8010000 which is unrecognized by fetchProcForPicture. A fix or work-around for the problem would be very much appreciated. It is holding up firefox 1.5 on OpenBSD.
Changed to All Hardware, All OS, Version 1.0.2 and Summary to better reflect the problem. It is very easy to reproduce the segfault on any hardware/os combo. Just set your Depth to 8, ssh -X localhost and attempt to run any gtk+2 application (firefox 1.5, gftp, cssed, etc). So far I have reproduced it on spark64, macppc and i386.
The problem has been isoloated to using a PseudoColor Visual with a card driver that doesn't support the RENDER extension. Depth 8 defaults to a PseudoColor Visual. To reproduce on any platform, any driver, just set DefaultDepth 8 and add this to turn off RENDER: Section "Extensions" Option "RENDER" "disable" EndSection
*** Bug 5520 has been marked as a duplicate of this bug. ***
We are having the same problems here under i686-pc-linux-gnulibc2. However, I cannot give any additional information, but I agree with Kurt Miller: We also would very much appreciate a fix or work-around since we'd like to migrate to the newest gtk+ on our 50 linux machines. I have tried gtk+-2.8.10 pango-1.10.2 cairo-1.0.2 my backtrace looks the same. Christoph Nodes, BFW Werner Völk GmbH
Seems like 5804 is a duplicate of this bug....
(In reply to comment #9) > Seems like 5804 is a duplicate of this bug.... This issue is probably the same as 4945. I have written a patch that fixes it. see: https://bugs.freedesktop.org/show_bug.cgi?id=4945 Kurt: I have posted it on the openbsd ports ML a while back.
*** This bug has been marked as a duplicate of 4945 ***
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.