July 25th, 2008


gdbing the X server with xkb ... finally..

So for a long time if you ran X inside gdb, gdb would die badly when X forked xkbcomp. X hackers have worked around this by either running -kb or attaching gdb after X is started for many years.

I finally found it by accident this morning, I was working on some modesetting things, and had been gdb'ing the X server fine, when suddenly it started doing the wierd hang, I realised I'd just enabled direct rendering code and initialised the lock.

Now the kernel has this really really really really dirty hack for the DRM that I'm not 100% sure we really need anymore. The original drm designers decided that if a DRI client held the lock then if it died it might crash the GPU, so they got this special signal blocking code into the Linux kernel which we use to block certains signals across lock hold. When the lock drops, the process gets the signal. Of course one of these signals was one gdb was using to stop the X server and the X server always holds the lock when running so it got confused when an blockable signals somehow managed to block itself :)

Now the fixes for this are

a) kill the notifier stuff, I'm not sure it ever mattered, I at least could kill it for modesetting drivers as we have a lot more
control over the GPU from the kernel.
b) Have the X server drop the DRI lock around certain operations like xkb execing xkbcomp etc.. this seems worse.

What I've done for now in drm git is just not set the notifier up for the "master" process, i.e. the X server. This will at least allow people to debug their X servers with xkb.