From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <326364c20807010802k6a4e78f2m7c3d681142e8034f@mail.gmail.com> Date: Tue, 1 Jul 2008 11:02:17 -0400 From: "Tom Lieber" To: "Russ Cox" Subject: Re: [9fans] tip 9vx segfault on Ubuntu in Xen Cc: 9fans@9fans.net In-Reply-To: <20080701141119.833401E8C35@holo.morphisms.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <326364c20807010702w6ebcb4e9m79d9cb16de1ffd83@mail.gmail.com> <20080701141119.833401E8C35@holo.morphisms.net> Topicbox-Message-UUID: d331bfdc-ead3-11e9-9d60-3106f5b1d025 On Tue, Jul 1, 2008 at 10:13 AM, Russ Cox 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 #2 sigsegv (signo=11, info=0x825522c, v=0x82552ac) at 9vx/main.c:500 #3 #4 sigsegv (signo=11, info=0x82555ac, v=0x825562c) at 9vx/main.c:500 #5 #6 sigsegv (signo=11, info=0x825592c, v=0x82559ac) at 9vx/main.c:500 #7 #8 sigsegv (signo=11, info=0x8255cac, v=0x8255d2c) at 9vx/main.c:500 #9 #10 sigsegv (signo=11, info=0x825602c, v=0x82560ac) at 9vx/main.c:500 #11 #12 sigsegv (signo=11, info=0x82563ac, v=0x825642c) at 9vx/main.c:500 #13 #14 sigsegv (signo=11, info=0x825672c, v=0x82567ac) at 9vx/main.c:500 #15 #16 sigsegv (signo=11, info=0x8256aac, v=0x8256b2c) at 9vx/main.c:500 #17 #18 sigsegv (signo=11, info=0x8256e2c, v=0x8256eac) at 9vx/main.c:500 #19 (More stack frames follow...) #0 0xffffe410 in __kernel_vsyscall () Is the last one legitimate? -- Tom Lieber http://AllTom.com/