On Tue, Jul 1, 2008 at 10:13 AM, Russ Cox <[EMAIL PROTECTED]> wrote: > When it stops, then can should attach gdb by > looking up the pid in ps and running > > gdb 9vx pid > thread apply all where 20 > > That's usually safer than running 9vx under > gdb from the start. 9vx is a multithreaded > program, so it would help to know what the > other threads are doing, not just the X11 thread.
Attaching doesn't seem to work in this case: Attaching to program: /home/tom/vx32/src/9vx/9vx, process 20840 /build/buildd/gdb-6.6.dfsg/gdb/linux-nat.c:1026: internal-error: linux_nat_attach: Assertion `pid == GET_PID (inferior_ptid) && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP' failed. A problem internal to GDB has been detected Searching for this error yielded an e-mail saying, "When Xorg hangs inside a signal handler, gdb is unable to attach to it." And "thread apply all where 20" has no output. However, if I run it from within gdb with -F, and ignoring SIGSEGV I get this: Thread 4 (Thread 1654795152 (LWP 20864)): #0 0xffffe410 in __kernel_vsyscall () #1 0x4011e676 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08053990 in runproc () at 9vx/sched.c:237 #3 0x0808f1cb in sched () at 9vx/a/proc.c:165 #4 0x08052842 in squidboy (v=0x828e8d0) at 9vx/main.c:723 #5 0x4011a46b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #6 0x4020073e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread 1645087632 (LWP 20863)): #0 0xffffe410 in __kernel_vsyscall () #1 0x4012237a in do_sigwait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x4012241f in sigwait () from /lib/tls/i686/cmov/libpthread.so.0 #3 0x0805675d in timerkproc (v=0x0) at 9vx/time.c:168 #4 0x0805723b in linkproc () at 9vx/trap.c:484 #5 0x00000000 in ?? () Thread 2 (Thread 1635380112 (LWP 20862)): #0 0xffffe410 in __kernel_vsyscall () #1 0x401f6647 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0x40061839 in ?? () from /usr/lib/libX11.so.6 #3 0x08272970 in ?? () #4 0x00000001 in ?? () #5 0xffffffff in ?? () #6 0x4006a67f in _X11TransWrite () from /usr/lib/libX11.so.6 #7 0x40061c2f in _XRead () from /usr/lib/libX11.so.6 #8 0x4006347b in _XReadEvents () from /usr/lib/libX11.so.6 #9 0x4004f6eb in XNextEvent () from /usr/lib/libX11.so.6 #10 0x080a1f37 in _xproc (v=0x0) at 9vx/x11/x11-kernel.c:141 #11 0x0805723b in linkproc () at 9vx/trap.c:484 #12 0x00000000 in ?? () Thread 1 (Thread 1076381360 (LWP 20859)): #0 sigsegv (signo=11, info=0x8254eac, v=0x8254f2c) at 9vx/main.c:500 #1 <signal handler called> #2 sigsegv (signo=11, info=0x825522c, v=0x82552ac) at 9vx/main.c:500 #3 <signal handler called> #4 sigsegv (signo=11, info=0x82555ac, v=0x825562c) at 9vx/main.c:500 #5 <signal handler called> #6 sigsegv (signo=11, info=0x825592c, v=0x82559ac) at 9vx/main.c:500 #7 <signal handler called> #8 sigsegv (signo=11, info=0x8255cac, v=0x8255d2c) at 9vx/main.c:500 #9 <signal handler called> #10 sigsegv (signo=11, info=0x825602c, v=0x82560ac) at 9vx/main.c:500 #11 <signal handler called> #12 sigsegv (signo=11, info=0x82563ac, v=0x825642c) at 9vx/main.c:500 #13 <signal handler called> #14 sigsegv (signo=11, info=0x825672c, v=0x82567ac) at 9vx/main.c:500 #15 <signal handler called> #16 sigsegv (signo=11, info=0x8256aac, v=0x8256b2c) at 9vx/main.c:500 #17 <signal handler called> #18 sigsegv (signo=11, info=0x8256e2c, v=0x8256eac) at 9vx/main.c:500 #19 <signal handler called> (More stack frames follow...) #0 0xffffe410 in __kernel_vsyscall () Is the last one legitimate? -- Tom Lieber http://AllTom.com/
