Bug 5846

Summary: Crash inside _get_image_surface() on 8-bit pseudocolor display Xlib surface
Product: cairo Reporter: Dave Beckett <dave>
Component: xlib backendAssignee: Carl Worth <cworth>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: high CC: R.Vickers
Version: 1.0.2   
Hardware: x86 (IA32)   
OS: Linux (All)   
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350217
Whiteboard:
i915 platform: i915 features:
Bug Depends on: 4945    
Bug Blocks:    

Description Dave Beckett 2006-02-09 15:27:34 UTC
This is a forwarding of a debian bug #350217 at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350217

Quoting partially:
[[
In _get_image_surface() in cairo-xlib-surface.c the code commented
"XXX This can't work." is getting used.  (Not a confidence-inspiring
comment :-).

It looks like the func _cairo_image_surface_create_with_masks() ends
up putting depth==0 in cairo_image_surface_t.  Still dunno if that's
normal, but it seems to get through to the XPutImage and the server
doesn't like it.

As a workaround I changed the code earlier in _get_image_surface()
from

	masks.alpha_mask = 0;
to
	masks.alpha_mask = 0xff;

This is a dirty hack, I guess it hard-codes 8-bit greyscale or
something.  But it has the effect of making the test

	if (_CAIRO_MASK_FORMAT (&masks, &format))

succeed, and the code under that leg using
cairo_image_surface_create_for_data() ends up giving depth==8, which
the server likes.  It makes all the problems I reported go away.

So my guess would be there's something dodgy in the code when an 8-bit
pseudocolor visual is in use, I'd imagine the problems should show up
for anyone with that.
]]

the debian bug report also contains the crash and a request dump, partially
quoted here:
[[
#4  0xb73441ff in _XError () from /usr/X11R6/lib/libX11.so.6
#5  0xb73448ef in _XReply () from /usr/X11R6/lib/libX11.so.6
#6  0xb733f215 in XSync () from /usr/X11R6/lib/libX11.so.6
#7  0xb733f2c3 in XSync () from /usr/X11R6/lib/libX11.so.6
#8  0xb733927b in XPutImage () from /usr/X11R6/lib/libX11.so.6
#9  0xb74034ac in cairo_test_xlib_disable_render () from /usr/lib/libcairo.so.2
...

	 ............REQUEST: PutImage
	     sequence number: 058b
	              format: ZPixmap
	      request length: 54fc
	            drawable: DWB 0140002d
	                  gc: GXC 0140002e
	               width: 012c
	              height: 0122
	               dst-x: 0
	               dst-y: 0
	            left-pad: 00
	               depth: 00
	                data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
	                    : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
	                    : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
	                    : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
	                    : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
	                    : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                              ...


				               Error (fd 5): 00 08 8b 05 2e 00 
40 01 00 00 48 08 00 00 00 00 50 d8 da bf 00 00 00 00 00 00 00 00 68 da da bf 
				 ..............ERROR: Match
				     sequence number: 058b
				        minor opcode: 0000
]]
Comment 1 Carl Worth 2006-05-03 04:23:04 UTC
Using cairo on an 8-bit pseudocolor display is not expected to work until cairo
acquires direct support for 8-bit pseducolor, (which it does not yet, see bug
#4945).

However, even once bug #4945 is fixed, there may still be a separate issue
related to the description here. But it's really not worth looking at closely
until the 8-bit support exists.
Comment 2 Chris Wilson 2008-09-29 03:25:54 UTC
Behdad and Carl completely overhauled low-bit depth support in the xlib-backend. First to support non-24bit drawables and then to provide dithering to psuedo-color visuals. The results are now quite reasonable... (Note to self, need to integrate testing of several bit depths into the test suite - requires running the test suite under Xvfb with different reference targets for each depth.)
Comment 3 Behdad Esfahbod 2008-09-29 04:56:46 UTC
Chris, no separate reference images should be needed.  Just very, very high tolerance values.

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.