Re: [bug-inetutils] already connected when closed

[Karl Berry]

    Can you put a break point at the fflush, and then examine the
    content in gdb

Sadly, both the cout FILE structure and struct stat from fstat are
identical in each of the two cases (connection still open & connection
died).  So I see no way to know in advance that it's going to failure.

    This bug is getting far to obscure...

I can't explain why it doesn't happen on other hosts (especially with
the exact same libc and kernel), but it doesn't actually seem like
unreasonable behavior: the socket times out, and this is only detected
at the fflush because that's when data is actually attempted to be
written.  According to the `Sending Data' node in libc.info, SIGPIPE is
to be expected.

I notice that ftp sets a SIGPIPE handler in some other cases, so I tried
adding 
  signal (SIGPIPE, lostpeer);

before the fstat.  That traps the SIGPIPE all right, but it seems
lostpeer isn't the right thing to do, as the next thing that happens is
an internal SIGSEGV in malloc:

#0  0xb7f178b0 in _int_malloc () from /lib/libc.so.6
#1  0xb7f19791 in malloc () from /lib/libc.so.6
#2  0xb7f0842f in __fopen_internal () from /lib/libc.so.6
#3  0xb7f084ed in fopen@@GLIBC_2.1 () from /lib/libc.so.6
#4  0xb7eac265 in internal_setent () from /lib/libnss_files.so.2
#5  0xb7eac6b7 in _nss_files_gethostbyname_r () from /lib/libnss_files.so.2
#6  0xb7f947f9 in gethostbyname_r@@GLIBC_2.1.2 () from /lib/libc.so.6
#7  0xb7f941b2 in gethostbyname () from /lib/libc.so.6
#8  0x0804ee93 in hookup (host=0x805ece5 "ftp.gnu.org", port=5376)
    at ftp.c:126
#9  0x0804a219 in setpeer (argc=2, argv=0x805eea0) at cmds.c:204
#10 0x08053047 in cmdscanner (top=1) at main.c:375
#11 0x08052dcb in main (argc=1, argv=0xbfffe478) at main.c:232

Maybe we want to ignore the SIGPIPE and just proceed normally in
setpeer with the NOOP failure.  I'll see if I can get anywhere with that.

karl