Re: [Filterproxy-devel] Re: FilterProxy BUG

[Bob M. <mce...@dr...>]

Guillaume Morin [gui...@mo...] wrote:
> Dans un message du 07 May =E0  9:48, Bob McElrath =E9crivait :
> > Well I'm stumped.  And bugs I can't reproduce are very hard to debug. :(
>=20
> I know, even I can reproduce it, I can't fix it :-)
>=20
> > But here are a few suggestions:
> >     1) If it's dying because getpeername is returning undef, why is
> >     getpeername returning undef?  getpeername is a system call
> >     (/usr/include/sys/socket.h)  What operating system/libc are you
> >     using?
>=20
> It is Linux 2.2.14 (tried too with .19) and glibc 2.1.3. Getpeername can
> return undef, if the syscall fails (here with ENOTCONN). If the peer has
> shutdown the connection, it looks logical to me.

The peer cannot shut down the connection.  This is a "listen" socket,
and should stay open when there are no connections.

The syscalls getpeername and accept are part of glibc.

> >     2) $daemon->accept is returning false or undef (line 295).
> >     IO::Socket (parent of HTTP::Daemon) is supposed to return undef upon
> >     'failure'.  The only failure I can see is if the port it is binding
> >     to is closed, or timeout, and clearly the latter is not happening.
> >     Under some circumstances (timeout) IO::Socket::accept returns an
> >     error code in $@.  Try printing out $@ in the "Exiting outside main
> >     loop (BUG!)" message.
>=20
> Yes, but accept(2) can't fail for other reasons that you should test
> such as ECONNRESET. After the getpeername error, I get EPIPE, I tried to
> launch accept again, it seems to trigger endless EPIPE errors.

This should not be possible.

The secondary connections (the HTTP::Daemon::ClientConn object returned
by accept()) should be resettable.  But the listen socket should not be
resettable.

> I do not know if you should ignore that one ... But there is surely a
> list of accept(2) errors that you want to ignore.

Hmmm good point.  I don't see how to get the linux error in perl.  All
the perl man pages just say it returns undef.

Do you know where to get this error code?  Maybe try printing out '$!'?

> >     3) It should be possible to work around this bug by re-initializing
> >     the HTTP::Daemon object.  (But I'd rather fix it!  ;)  Add a big
> >     while loop around the main loop and do this at the end of it:
> >         $daemon =3D undef;
> >         $daemon =3D new HTTP::Daemon LocalAddr =3D> $HOSTNAME,=20
> >                                       LocalPort =3D> $LISTEN_PORT,
> >                                       Reuse     =3D>  1, Listen =3D> 40
> >            or croak "HTTP::Daemon failed to initialize: $!\n"
> >               . "Is $HOSTNAME:$LISTEN_PORT correct?";
> >     The latter is copied from around line 189.
>=20
> Yes I'd prefer to fix it too. Unfortunately, This does not work since
> the port is already bound. I tried to do a $daemon->close before that,
> but it did not help.

The accept(2) man pages says to retry when it gives odd errors.  Maybe
rearrange that main loop:
    while(1) {
        my $client =3D $daemon->accept;
        next unless(defined $client);
    ...
    }

Maybe throw a sleep() in there so it doesn't consume 100% of the cpu if
the network goes down (or something).

Cheers,
-- Bob

Bob McElrath (rsm...@st...)=20
Univ. of Wisconsin at Madison, Department of Physics