Re: more info on networking trouble

[Roland McGrath]

> I didn't follow that track, because it was coming from libwrap (tcp
> wrapper), and I was not set up to debug there. Instead, I let inetd start
> telnetd directly, and attached gdb to pfinet before doing so.

tcpd just execs telnetd after doing the access check.  So when you have an
open connection, you have a normal telnetd process that is a child of inetd
whether or not you use tcpd.  All that I was suggesting was attaching gdb
to the running telnetd and seeing what it is doing when it is hung.

> Seriously, I think this is some trouble with the condition_wait/select
> stuff. Pending bytes don't seem to be delivered or wake a waiting select.

Well, we know that much.  We need to get more specific.  That's why I
wanted to see exactly what RPC was blocking (i.e. is it select or is it
read).  

> But this is not everything, I also saw this:
> 
> S_io_read (user = 0x700807f9, data=0x740130be, datalen=0xff0130be,
> offset = 16777215, amount = 117440516)
> 
> and a quick death with EXC_BAD_INSTRUCTION in io-ops.c, l 87 afterwards.
> So there is some serious memory corruption taking place, too, as the
> parameters are obviously bogus.

You might turn on some of the libc debugging stuff when starting pfinet.
You didn't show me the whole context, but that might also just be a
confusion in the stack analysis by gdb.  When there is a crash, always cite
the complete backtrace, and also "x/5i $pc" and "i reg" at frame 0.