Xserver and gdb

Michel Dänzer michel at daenzer.net
Mon Jan 30 08:55:33 PST 2006


On Sat, 2006-01-28 at 16:26 +0100, Jacek Popławski wrote:
> 
> After each X crash/lock I go to another computer, use ssh to connect, then "gdb
> /usr/bin/X pid", and then store backtrace into the file. I can continue process
> (with "c"), but server doesn't respond to mouse/keyboard input.

The server is probably stuck in an infinite loop then.

> Do I understand correctly that X are not multithreaded? 

Yes, hence such a loop appears like a lockup locally.


> #4  0xb7e51e69 in ioctl () from /lib/tls/libc.so.6
> #5  0x080e6530 in xf86ioctl ()
> #6  0xb7a11a92 in drmCommandNone () from /usr/lib/xorg/modules/linux/libdrm.so
> #7  0xb79d0e1a in RADEONWaitForIdleCP (pScrn=0x82139e8)
>     at radeon_commonfuncs.c:137

Looks like a classic hardware lockup. The driver is waiting indefinitely
for the hardware to catch up. 


> - recompile X/Mesa/drm with debugging symbols because important stuff is "??"
> or symbols are wrong?
> 
> - submit such backtraces as bug?
> 
> - fix something obvious?

None of this tends to be very useful with hardware lockups, which are
usually caused by 3D (or 2D/3D synchronization) driver bugs. Your best
bet is probably filing a bug with as much information as possible on how
to reproduce the problem, ideally a small test program.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



More information about the xorg mailing list