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.
Created attachment 2936 [details] [review] prevent SEGV if XRenderFindStandardFormat returns NULL
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?
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 */
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.
Move bugs against "cvs" version to "0.9.3" so we can remove the "cvs" version.
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).
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.
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.