Created attachment 49306 [details] backtrace full X server receives SIGSEGV due to null-pointer dereference. The problem is that pixman_image_create_bits returns NULL and the code does not expect this to happen. It returns NULL because picture's BPP (24) is less than DEPTH (32). ================================ (gdb) b render.c:721 Breakpoint 1 at 0xb775428e: file /var/tmp/portage/x11-base/xorg-server-1.10.3/work/xorg-server-1.10.3/render/render.c, line 721. (gdb) cond 1 ((*(PicturePtr)pDst)->format >> 24) < (((*(PicturePtr)pDst)->format >> 12) & 0x0f) + (((*(PicturePtr)pDst)->format >> 8) & 0x0f) + (((*(PicturePtr)pDst)->format >> 4) & 0x0f) + (((*(PicturePtr)pDst)->format) & 0x0f) (gdb) c Continuing. /**************** I couldn't trace the problem further. In render.c on line 720 VERIFY_PICTURE returns a picture in pDst. The condition is the inverted one from pixman-bits-image.c on line 1564 (PIXMAN_FORMAT_BPP < PIXMAN_FORMAT_DEPTH). If execution breaks it means that this check will fail later. ****************/ /**************** I press Alt+F2, type “restart” and hit Enter. ****************/ Breakpoint 1, ProcRenderComposite (client=0xb7d6a288) at /var/tmp/portage/x11-base/xorg-server-1.10.3/work/xorg-server-1.10.3/render/render.c:721 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0xb74d7eae in pixman_image_set_has_client_clip (image=0x0, client_clip=1) at /var/tmp/portage/x11-libs/pixman-0.22.2/work/pixman-0.22.2/pixman/pixman-image.c:484 ================================ I didn't manage to find out where did this invalid picture come from. See complete backtrace in the attachment. xorg-server-1.10.3 KDE 4.6.5 Under Gentoo Linux in qemu-kvm (git) terminal ~ # uname -a Linux terminal 2.6.39-hardened #4 SMP PREEMPT Tue Jul 19 13:38:28 MSD 2011 i686 QEMU Virtual CPU version 0.14.50 GenuineIntel GNU/Linux
Is this a regression? If so, what was the last version you tried that did not exhibit this problem?
This is a synthetic environment, so there was no previous version. But we'll try to see if this is a regression. The main question is who to blame: KDE or X? But, anyway, this part of code shouldn't crash.
Please do not change the component and severity. This is a server crash which warrants P2. Not blocking 1.12 as this is not known to be a regression. You seem to have diagnosed the issue a tad. Would you mind sending a patch for the NULL return check sub-issue and sending to xorg-devel for review? """ The problem is that pixman_image_create_bits returns NULL and the code does not expect this to happen. It returns NULL because picture's BPP (24) is less than DEPTH (32). """ If not, I'll get to it eventually, but I've still got another 1500 bug reports to screen before I start fixing any without patches. I understand that the underlying cause still needs to be found, but rendering bad or sending an error to the client is better than crashing.
Created attachment 51972 [details] [review] Fix server crash due to invalid images Sorry I didn't want to change anything, this was not intentionally. I'm not familiar with X server code at all, so the best thing I can suggest is simply returning NULL. As I can see, this case is handled correctly in top-level functions (e.g. see fb/fbpict.c:65).
Thanks.
I want to bring the NULL check into 1.11, so adding to that tracker for that quick fix.
Thanks, the NULL check is in my for-keith branch and will be pulled to master soon (and then 1.11)
Søren, can you take a look at this one? In create_bits_picture in fbpict.c, the call to pixman_image_create_bits looks wrong. What's with that " * sizeof(stride)"? It was added in: commit 54e023cec07aa7e392da36e11d0a4667b8341370 Author: Søren Sandmann Pedersen <sandmann@redhat.com> Date: Mon Jun 11 09:16:46 2007 -0400 Don't pass regions to pixman_image_composite() anymore.
The NULL check is in 1.11. Moving this to 1.12 for the underlying fix.
The "* sizeof (FbStride)" is correct because the fbGetPixmapBitsData(pixmap, bits, stride, bpp); macro computes stride as "number of FbStride", and pixman expects the stride to be given in number of bytes. The problem is that something in the X server generates a bogus format with 24 bits per pixel, but 32 bits of channel data (a, r, g, and b). It is likely that the problem is to be found in PictureCreateDefaultFormats() where the default formats are created. Something there is creating a bogus format which is later used for pictures.
Alternatively, it may be that some variant of http://patchwork.freedesktop.org/patch/1327/ is what's needed.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
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.