Created attachment 37299 [details]
Add a guard to prevent null pointer de-reference

We run some UI tests for our Eclipse/SWT-based application inside Xvfb using SWTBot.  Recently the Xvfb session started crashing during the tests, with the following stack trace:

#0  0x00ab3424 in __kernel_vsyscall ()
#1  0x0074fa81 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x0075134a in abort () at abort.c:92
#3  0x081bcbeb in AbortServer () at log.c:408
#4  0x081bd21e in FatalError (f=0x81d811c "Caught signal %d (%s). Server
aborting\n") at log.c:530
#5  0x081b5a70 in OsSigHandler (signo=11, sip=0xbfa154bc, unused=0xbfa1553c) at
osinit.c:156
#6  <signal handler called>
#7  miDCRestoreUnderCursor (pDev=0x8d9fc80, pScreen=0x8c09088, x=-9, y=-9,
w=35, h=44) at midispcur.c:576
#8  0x081a1ca3 in miSpriteRemoveCursor (pDev=0x8d9fc80, pScreen=0x8c09088) at
misprite.c:995
#9  0x081a2ab2 in miSpriteSetCursor (pDev=0x8d9fc80, pScreen=0x8c09088,
pCursor=0x8dd1ac0, x=172, y=12) at misprite.c:895
#10 0x081a2be0 in miSpriteMoveCursor (pDev=0x8d9fc80, pScreen=0x8c09088, x=172,
y=12) at misprite.c:922
#11 0x0819c465 in miPointerUpdateSprite (pDev=0x8d9fc80) at mipointer.c:428
#12 0x08080f9a in ProcXTestFakeInput (client=0x8e6c400) at xtest.c:454
#13 0x0815bcd7 in Dispatch () at dispatch.c:439
#14 0x0814b71a in main (argc=8, argv=0xbfa15c64, envp=0xbfa15c88) at main.c:285

This is Xorg 1.7.6 as shipped by Fedora Core 12.

Line 576 of midispcur.c is inside miDCRestoreUnderCursor and is:
 pSave = pBuffer->pSave;

Searching the freedesktop.org bugzilla yielded two very similar bugs: bug 24181 and bug 27942.  These seem to relate to the same de-referencing (pSave = pBuffer->pSave;) but inside miDCSaveUnderCursor rather than miDCRestoreUnderCursor

Our problem appears to have been solved by simply guarding the dereferencing of pBuffer in miDCRestoreUnderCursor with:
    if (!pBuffer)
        return FALSE;

(see attached patch).

I don't know if a similar guard on line 536 would solve the other bugs mentioned above, and I also don't know if the bug would be better fixed elsewhere rather than simply adding this guard.  Having said that the guard does seem to solve the problem for us.

Unfortunately we don't have a simple set of steps to reproduce this problem, as it only occurred for us during a large set of tests of one of our products.