Created attachment 34860 [details] [review]
Patch to check NULL pointer and protect from crashing desktop.
Seems to be driver dependent... the (pScreen->CreatePixmap)() function can return NULL pointer under certain circumstances, generally because the driver finds something wrong with the input values (too large, etc) and the ProcRenderAddGlyphs() function does not check this return pointer. Thus, feeding certain glyph data can crash the X11 server and badly behaved applications are known to feed such data.
Worse yet, the maintainers of the badly behaved application (e.g. wine) will not fix their bugs when they see the X11 server crashes because after all, that must be an xorg problem (see wine bug #19986 to be told, "Still, an X11 crash is not a Wine bug"). Until I can get you guys to fix the crash at your end, the application maintainers will continue to ignore the problem.
You can look at Ubuntu Launchpad bug #408016 which has a demo program that will crash certain versions of Unbunu when run with Intel 945GM/GMS/GME graphics (a very common chip on low-end laptops). Since the exact data required to get this crash to happen depends on many driver-level details, I can't guarantee a crash on non-Ubuntu systems, and I know it does not crash on Nvidia hardware).
I've attached a patch in the hope that it may be useful. It is a very small patch, easy to check and the only question is whether to return BadAlloc or BadValue but I would say that BadValue is more likely to be a correct cause of the problem (in actual fact, there is no way to be 100% sure why the driver rejected this particular data, it may be a genuine BadAlloc).
On Sat, Apr 10, 2010 at 00:22:12 -0700, email@example.com wrote:
> Patch to check NULL pointer and protect from crashing desktop.
can you send this patch to firstname.lastname@example.org for review?
Patch from git-format-patch sent to devel list.
Patch is against X11R7.5 archive sha1sum:
Reassigning to core as this is not driver specific, and patch is en route.
A modified version of the patch was applied to git master:
so marking this bug as fixed. Thanks for bringing this to our attention.