Summary: | multiple test SEGVs because of NULL return from XRenderFindStandardFormat | ||
---|---|---|---|
Product: | cairo | Reporter: | Tim Mooney <Tim.Mooney> |
Component: | general | Assignee: | 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
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.