Comment 13 for bug 526919

Thanks for collecting a backtrace. As Timo suggests, it would be helpful to verify this still occurs on Lucid. But I can give you some tips if you want to continue debugging it on karmic.

First, you mentioned this started happening only after a recent update. A straightforward step would be to go through /var/log/dpkg.log and one by one downgrade suspect packages that were updated until you find the update which led to the regression.

Second, in examining the startkde script (thanks for including it), one of the things that happens beforehand is fiddling with themes and cursor parameters. Since the crash occurs in ProcXFixesGetCursorImageAndName() this seems suspicious. Starting with the startkde script you posted, try commenting out lines in the file to simplify it down to a shorter script so it's clearer which sequence of commands lead to the crash.

A third approach would be to debug it bottom up in the source code. It seems this is crashing in the routine privateExists() in dix/private.c in the xorg-server package. The code in question is:

static _X_INLINE int
privateExists(PrivateRec **privates, const DevPrivateKey key)
{
    return *key && *privates &&
        (*privates)[0].state > *key &&
        (*privates)[*key].state;
}

That's a lot of pointer dereferencing, and it's possible one of those pointers is either null or undefined (pointing to a random and inappropriate area of memory). This is a type of bug that's rather hard to diagnose based only on logs and backtraces, but should be suitable to debugging if you have access to the machine.

Run gdb and crash the server. Verify you have the same backtrace you got before. Now use gdb to examine the privates variable and its contents.

Hope this helps, and good luck.