gdb of crash and ktrace from DragonFly (and remote access to DragonFly for xserver work)

[Matthieu Herrb]

Jeremy C. Reed wrote:
> On Sat, 11 Mar 2006, Matthieu Herrb wrote:
> 
>> I'd suggest you try with 'Option "NoTrapSignals" "True"' in the 'ServerFlags'
>> section in xorg.conf. This will probably provide a better stack trace.
> 
> Thanks.
> 
> This is the Xorg core dump of when I attempt to start a client.
> 
> (gdb) bt
> #0  0x281aec72 in tls_get_addr_common () from /usr/libexec/ld-elf.so.2
> #1  0x281b0e6c in ___tls_get_addr () from /usr/libexec/ld-elf.so.2
> #2  0x28373ee5 in .cerror () from /usr/lib/libc.so.6
> #3  0x28381824 in ?? () from /usr/lib/libc.so.6
> #4  0x283112f1 in usleep () from /usr/lib/libc.so.6
> #5  0x080d3ed3 in xf86usleep (usec=300000) at ./../shared/libc_wrapper.c:1199
> #6  0x284607bb in MouseProc (device=0x822e100, what=0) at mouse.c:1778
> #7  0x08079daf in CloseDevice (dev=0x822e100) at devices.c:213
> #8  0x08079e80 in CloseDownDevices () at devices.c:294
> #9  0x0806c32d in main (argc=1, argv=0xbfbffbcc, envp=0xbfbffbd4) at 
> main.c:469

Ok, so your previous it was not an artefact caused by the signal handler 
run with a corrupted stack. The X server really segfaults in usleep(). 
This is pretty strange.

> 
> Now with NoTrapSignals, my screen never gets reset. Is there any tool for 
> resetting my screen so I can see my console again (without rebooting)?

Unfortunatly no, at least not in the BSD world using wscons. Only the X 
server knows how to restore the console text mode.
My past attempt to use X's int10 code to write an application that would 
reset a text mode with help of the BIOS (possibly as rude as POST'ing 
the card) didn't really work.

> 
> I have repeated the above (same gdb backtrace with different core dumps) a 
> few times. The last time I used a libX11 that was built with 
> --disable-xthreads. I ran:
> 
> glacier# env LD_LIBRARY_PATH=/home/reed/xorg/lib /home/reed/xorg/bin/xlsclients -display :0
> XIO:  fatal IO error 54 (Connection reset by peer) on X server "localhost:0.0"
>       after 3 requests (0 known processed) with 0 events remaining.
> 
> Then the Xorg display hung. Xorg crashed and I got a core dump (back trace 
> is above.
> 
> Probably not related, but I can also get consistent segmentation faults 
> immediately at Xorg startup when /tmp/.tX0-lock exists at startup (and 
> maybe /tmp/.X0-lock also):
> 
> (gdb) bt
> #0  0x281aec72 in tls_get_addr_common () from /usr/libexec/ld-elf.so.2
> #1  0x281b0e6c in ___tls_get_addr () from /usr/libexec/ld-elf.so.2
> #2  0x28373ee5 in .cerror () from /usr/lib/libc.so.6
> #3  0x081b62c4 in ?? ()
> #4  0x08182a9b in LockServer () at utils.c:477
> #5  0x081825e1 in OsInit () at osinit.c:208
> #6  0x0806bfe3 in main (argc=1, argv=0xbfbffaac, envp=0xbfbffab4) at 
> main.c:315
> (gdb)
> 
> I remove that file and then Xorg starts (and I can move the mouse but no 
> clients will run or I get the first core dump as showed above).

This is strange too. Can you try upping your stack size limit ?
-- 
					Matthieu