[Filterproxy-devel] Re: FilterProxy BUG

[Guillaume M. <gui...@mo...>]

Dans un message du 02 May à 10:57, Bob McElrath écrivait :
> This may seem unrelated...but the only thing I can think of is if you're
> exhausting the available sockets or something.  Somehow the socket is
> getting closed forcibly.  (maybe exhausting a per-user process or socket
> limit?)  This seems reasonable if you reload a page with lots of images
> many times -- lots of FilterProxy activity.

I don't think so. I've done a strace of the main processe. I saw no
signal or errors related to limits. The only error was getpeername
returning ENOTCONN, just as Perl reports.

> Try adding this somewhere inside data_handler in FilterProxy.pl:
> 
>     if(!defined $client->connected()) {
>         die("Client aborted download");
>     }
> 
> This should close outgoing connections when you hit "stop".  

I tried this. It happens sometimes (I've added a logger call), but the
main process still dies.

> Do you hit
> reload repeatedly, and wait for the page to finish each time?  Or do you
> hit reload without waiting for the page to finish?  (the above patch
> might help in the latter case)

The crash happens when you load a page and click stop.

> Can you tell me how many FilterProxy processes there are just before it
> crashes?
>     ps aux | grep FilterProxy
> and network connections? 
>     netstat -anp | grep FilterProxy

The results are very different. It varies from about 5 process or
connections to 40.

> And what is the version of LWP and HTTP::Daemon that you have installed?

It is LWP 1.00 and libwww 5.43 (I tried to upgrade to LWP 5.47, but it
did not help)

> My only other suggestion is to upgrade your perl, as this could be
> caused by a perl bug (and let me know if that works...).

Unfortunately, I cannot do that. I must keep that version atm :-(.

Thanks for your help.

Regards,

-- 
Guillaume Morin <gui...@mo...>