On Wed, 2009-04-29 at 17:43 +0200, Richard Körber wrote: > I, for one, wasn't aware of that because I know next to nothing about > the internas of the X server. Counting the number of comments on that > bug, I guess I wasn't the only one though. :-) Some days I wish I knew less about it. > > In this particular case, it's something much more lame: > > > > (gdb) bt > > #0 0x00de3f73 in pixmanBltsse2 (src_bits=0xa8587000, > > dst_bits=0xa0587000, src_stride=1408, dst_stride=1408, src_bpp=32, > > dst_bpp=32, src_x=0, src_y=0, dst_x=0, dst_y=0, width=1299, > > height=15000) at pixman-sse2.c:4530 > > [...] > > Is there an easy way to generate traces like that for a new bug report, > in case a EQ overflow should strike again? You need a second machine. ssh into the one that locked up, sudo debuginfo-install xorg-x11-server xorg-x11-drv-\*, sudo gdb /usr/bin/Xorg `pidof Xorg`, bt. See also: http://wiki.x.org/wiki/Development/Documentation/ServerDebugging There are some cases where this won't work. Some of the DRM ioctls are not interruptible, which means gdb won't be able to attach to the process. If that happens there's almost certainly something in dmesg to indicate that something's gone south. However, since they're not interruptible, SIGIO won't get delivered either, which means the mouse won't move, so you should at least have some idea ahead of time which kind of lockup you're facing. Note the various grades of lockup: - can't even ssh in - can ssh in, but can't attach with gdb - can attach with gdb Even being able to distinguish among these cases goes a long way towards locating the bug. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
