Re: pfinet & ftp & hang in select

[Roland McGrath]

You don't seem to have debugging symbols for your shared libraries.  That
is important so we can see all the function arguments.  Also note e.g. all
the ports_manage_port_operations_one_thread frames are actually a
misidentification.  Those frames are really in the nested function inside
ports_manage_port_operations_multithread, whose code lies at a local symbol
before the ports_manage_port_operations_multithread entry point; it just so
happens that ports_manage_port_operations_one_thread is the preceding
global symbol, and so that's what gdb shows you.  (Incidentally, gdb ought
to be a little more helpful about this--even without debugging symbols, it
can tell from the prior symbol's st_size that the address in question does
not actually lie in that function.)

BTW, see the gdb command "thread apply", e.g. try "thr appl all bt".

There appear to be multiple server threads blocked in S_io_select for the
same user port (e.g. user=0x807e720).  That is probably bogus.  It seems
doubtful that there are actually two users both doing select on the same
socket.  I suspect that an old io_select RPC is not getting properly
cancelled.  (This alone could explain the extra threads, but not the buggy
behavior you see.)  You might do some diagnostic kludges to check for that,
e.g. add a field someplace tracking outstanding selects on a protid or on a
socket and trap if there are more than one; you can make your hack check
directly for the TCP port number of ftp to avoid hitting on random stuff
other than your test case.


I have only given a cursory glance to your rpctrace output.  But I've just
checked in a couple of changes that should fix some suspect (but harmless)
things in the output.