Summary: | segmentation fault when running gtk (with cairo) applications at Depth 8 | ||
---|---|---|---|
Product: | cairo | Reporter: | Dumitru Sipos <dumitru.sipos> |
Component: | image backend | Assignee: | Carl Worth <cworth> |
Status: | RESOLVED DUPLICATE | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | critical | ||
Priority: | high | CC: | kurt, matthieu.herrb, nodes |
Version: | 1.0.2 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Dumitru Sipos
2005-09-19 02:35:20 UTC
----------------------------------------------------------------------------- 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.