[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more info on networking trouble
From: |
Roland McGrath |
Subject: |
Re: more info on networking trouble |
Date: |
Wed, 17 Jan 2001 00:06:51 -0500 (EST) |
> 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.