[9fans] tip 9vx segfault on Ubuntu in Xen

[9fans] tip 9vx segfault on Ubuntu in Xen

[Tom Lieber]

I have Ubuntu on a VPS (on Xen) and I'd like to install a Plan 9
server using 9vx. 9vx tip compiles, but segfaults after the "256M
memory" line (as does the precompiled binary, in the same place). I am
tunneling to local X11 on OS X 10.5.3.

I don't know how to debug this properly, but here is gdb output
similar to what I saw in another report.

Starting program: /home/tom/vx32/src/9vx/9vx -F -u glenda
[Thread debugging using libthread_db enabled]
[New Thread 1076381360 (LWP 19044)]
[New Thread 1635380112 (LWP 19047)]
[New Thread 1645087632 (LWP 19048)]
[New Thread 1654795152 (LWP 19049)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076381360 (LWP 19044)]
0x08099acc in sysexec (arg=0x602852d0) at 9vx/a/sysproc.c:386
386             tos->cyclefreq = m->cyclefreq;
(gdb) bt
#0  0x08099acc in sysexec (arg=0x602852d0) at 9vx/a/sysproc.c:386
#1  0x08057abc in trap (ureg=0x60b48ee0) at 9vx/trap.c:222
#2  0x08058968 in touser (initsp=0xfffffa4) at 9vx/vx32.c:284
#3  0x08052421 in init0 () at 9vx/main.c:487
#4  0x00000000 in ?? ()
(gdb) info thread
  4 Thread 1654795152 (LWP 19049)  0xffffe410 in __kernel_vsyscall ()
  3 Thread 1645087632 (LWP 19048)  0xffffe410 in __kernel_vsyscall ()
  2 Thread 1635380112 (LWP 19047)  0xffffe410 in __kernel_vsyscall ()
* 1 Thread 1076381360 (LWP 19044)  0x08099acc in sysexec (arg=0x602852d0)
    at 9vx/a/sysproc.c:386
(gdb) info threads
  4 Thread 1654795152 (LWP 19049)  0xffffe410 in __kernel_vsyscall ()
  3 Thread 1645087632 (LWP 19048)  0xffffe410 in __kernel_vsyscall ()
  2 Thread 1635380112 (LWP 19047)  0xffffe410 in __kernel_vsyscall ()
* 1 Thread 1076381360 (LWP 19044)  0x08099acc in sysexec (arg=0x602852d0)
    at 9vx/a/sysproc.c:386

--
Tom Lieber
http://AllTom.com/

Re: [9fans] tip 9vx segfault on Ubuntu in Xen

[Russ Cox]

> I have Ubuntu on a VPS (on Xen) and I'd like to install a Plan 9
> server using 9vx. 9vx tip compiles, but segfaults after the "256M
> memory" line (as does the precompiled binary, in the same place). I am
> tunneling to local X11 on OS X 10.5.3.
>
> I don't know how to debug this properly, but here is gdb output
> similar to what I saw in another report.

The seg faults are normal.  9vx handles them and continues.
To run under gdb you need to say

	handle SIGSEGV noprint nostop

so that gdb will let it keep going.

What behavior did you see when you weren't running under gdb?
If it was a panic, better to set a break point at panic.

Russ

Re: [9fans] tip 9vx segfault on Ubuntu in Xen

[Tom Lieber]

On Tue, Jul 1, 2008 at 9:00 AM, Russ Cox <rsc@swtch.com> wrote:
>> I have Ubuntu on a VPS (on Xen) and I'd like to install a Plan 9
>> server using 9vx. 9vx tip compiles, but segfaults after the "256M
>> memory" line (as does the precompiled binary, in the same place). I am
>> tunneling to local X11 on OS X 10.5.3.
>>
>> I don't know how to debug this properly, but here is gdb output
>> similar to what I saw in another report.
>
> The seg faults are normal.  9vx handles them and continues.
> To run under gdb you need to say
>
>        handle SIGSEGV noprint nostop
>
> so that gdb will let it keep going.
>
> What behavior did you see when you weren't running under gdb?
> If it was a panic, better to set a break point at panic.

No panic: the window appears and two lines print (the command-line
arguments and the memory readout), then everything stops. When I use
-X, the lines of assembly stop.

This looks useless, but if I pause in gdb the backtrace is:

#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  0x40111b2c in ?? () from /usr/lib/libX11.so.6
#7  0x082723c0 in ?? ()
#8  0x40111b2c in ?? () from /usr/lib/libX11.so.6
#9  0x082723c0 in ?? ()
#10 0x00000000 in ?? ()

If I press keys, though, I get output like this, so I guess it's not
completely frozen:

memdraw 827b780 [4 57] [13 68] 8269da8 [1879113727 -613566757] 8269e60 [918 2]
memdraw 827b780 [13 57] [22 68] 8269da8 [1879113727 -613566757] 8269e60 [918 2]
memdraw 827b780 [22 60] [31 68] 8269da8 [1879113727 -613566757] 8269e60 [873 5]

It never does anything as long as I wait, though.

--
Tom Lieber
http://AllTom.com/

Re: [9fans] tip 9vx segfault on Ubuntu in Xen

[Russ Cox]

> No panic: the window appears and two lines print (the command-line
> arguments and the memory readout), then everything stops. When I use
> -X, the lines of assembly stop.

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.

Thanks.
Russ

Re: [9fans] tip 9vx segfault on Ubuntu in Xen

[Tom Lieber]

On Tue, Jul 1, 2008 at 10:13 AM, Russ Cox <rsc@swtch.com> 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/