Bug 4142

Summary: multiple test SEGVs because of NULL return from XRenderFindStandardFormat
Product: cairo Reporter: Tim Mooney <Tim.Mooney>
Component: generalAssignee: Carl Worth <cworth>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: high CC: keithp
Version: 0.9.3   
Hardware: Alpha   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: prevent SEGV if XRenderFindStandardFormat returns NULL

Description Tim Mooney 2005-08-19 14:02:44 UTC
I'm building cairo 0.9.2 on Tru64 UNIX with the vendor toolchain.  I have lots
of other opensource software installed, but particularly relevant for cairo is:

libpng 1.2.8
Mesa 6.2.1
glitz 0.4.4
renderext 0.9.1
libXrender 0.9.1
fontconfig 2.2.95
freetype 2.1.9

while doing a

  gmake check

about 39 of the 49 tests fail, most of the them with SEGVs.  Doing some
debugging, it looks like most of these are coming in the call

    xtc->pixmap = XCreatePixmap (dpy, DefaultRootWindow (dpy),
                 width, height, xrender_format->depth);

on about line 388 of cairo-test.c.  The problem is apparently that the prior
call

    xrender_format = XRenderFindStandardFormat (dpy, PictStandardARGB32);

has returned NULL, for reasons I haven't yet determined.  In any case, if I add
a check for NULL and a message to cairo_test_log, this particular SEGV no longer
happens.

The simple patch is attached.
Comment 1 Tim Mooney 2005-08-19 14:05:18 UTC
Created attachment 2936 [details] [review]
prevent SEGV if  XRenderFindStandardFormat returns NULL
Comment 2 Carl Worth 2005-08-19 17:00:27 UTC
We can apply this patch I guess, but there's a deeper problem here.

The cairo implementation itself also calls XRenderFindStandardFormat
and doesn't check for a NULL return value.

Isn't that function supposed to be guaranteed to return non-NULL
when called with PictStandardA1, PictStandardA8, or PictStandardARGB32?

What are you getting from the xlib tests after you apply this patch? 
Comment 3 Owen Taylor 2005-08-20 05:34:09 UTC
A NULL return here simply means that the server doesn't have the RENDER
extension. In the implementation of Cairo we are checking for the RENDER
extension first so the problem shouldn't happen. (As long as we are happy
with segfaulting on a buggy Xserver, which I think is not worth trying
to guard against.)

In terms of testing on server's without RENDER, the situation is much
like Win32:

 - There is no API to create a *native* ARGB32 surface; create_similar()
   just creates an image surface.
 - All drawing on an ARGB32 surface would be done with fallbacks to
   the image backend anyways.
 - If we added RGB24 tests it might be more interesting (especially if
   we added more intelligent fallback code)

But then again, if we had code paths that were interesting to test in
the no-RENDER case, I'd like to run those tests even when the server
has render using cairo_test_xlib_disable_render().

For right now, I think the patch is right (though maybe it needs a comment
/* Skip Xlib tests if the server doesn't have RENDER */
Comment 4 Carl Worth 2005-08-20 07:55:32 UTC
Ah, thanks for the explanations Owen. That makes a lot of sense.

The fix has been committed now:

2005-08-20  Carl Worth  <cworth@cworth.org>

        Fix for bug #4142:

        * test/cairo-test.c (create_xlib_surface): Disable xlib tests on X
        servers without the Render, since they currently just crash
        there. A better long-term fix would be to do some useful tests in
        this case. Thanks to Tim Mooney.
Comment 5 Carl Worth 2005-08-22 17:14:36 UTC
Move bugs against "cvs" version to "0.9.3" so we can remove the "cvs" version.
Comment 6 Tim Mooney 2005-09-07 15:55:17 UTC
Sorry to comment on a RESOLVED FIXED item, but I thought I would add a couple
points:

- to answer Carl's question in comment #2, with the patch applied all of the
*-xlib tests show as UNTESTED in the output from "make check".

- the README in cairo-1.0.0 indicates that the xlib backend requires "Xrender >
0.6", however Owen's comments on this issue imply something that might not be
obvious to others: the xlib backend requires the Xrender API
(renderext/libXrender) *and* it requires that your X server supports the X
render extension.  Using the stock Tru64 X server I don't have the second
requirement, so I'm assuming that's why all the xlib tests are "UNTESTED".

If I've arrived at the correct conclusion, you might wish to update the README
to make it clear to others that having the API installed isn't enough to get the
xlib backend.

I don't know if freedesktop.org is using the "VERIFIED" state for bugs, but I
have verified that 1.0.0 fixes this particular issue (SEGVs in
XRenderFindStandarFormat for many tests).
Comment 7 Owen Taylor 2005-09-07 15:58:20 UTC
The Xlib backend does not require the RENDER extension. It falls back
to doing drawing client side.

What my comments are saying is that it doens't make sense to, when
you run make check test:

 - Client side drawing via the image surface
 - The same client side drawing as fallbacks for the xlib backend

But if the server has RENDER, then we want to check the separate RENDER
codepath.
Comment 8 Tim Mooney 2005-09-07 16:04:59 UTC
Thanks for dispelling my confusion.

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.