Jonathan Houser wrote:
Yeppers, the client ones. I just checked all of my logs, and the
only IPs I see regarding WAP are the ones from an IP I have blocked.
Regardless, it'd be very helpful if they were on the same line in the
same log as the fetch itself: correlating traffic is hard -- especially
when you have a lot of requests per the same second at times. I'm
guessing the IP is not passed to wapbox for abstraction purposes, and
thus only bearerbox really knows it? It'd still be nice if wapbox knew
it, if only for writing more descriptive log lines. I'd happily write
such a patch if you'd like one.
ok, go ahead. wapbox of course knows the remote client IP address. For an
example, see gw/wap-appl.c:760 where the alog() call is done to log the request
to the wapaccess.log file.
ok, so the assumption is: We get leaking file descriptors when HTTPS
addresses are requested and some openssl write error occures, right?
That's one of the cases that cause it, yes. Not the one I see the
most (usually it's that 'ERROR: WTP: cannot unpack pdu, creating an
error pdu'), but one I can reproduce at will. As I've said, it appears
to deal with all WAP error condition cleanup.
ok, I'll review the error handling here and check.
It leaks them -- just *very* slowly. I think the last thing I
quoted was 14 in 16 hours or something like that. And that was through
our 16 busiest hours of the day.
ok, so obviously there has been at least a "change" that made the leaking
more
aggressive
.
Generally the error code 1 for the SSL_read/write here means from
openssl docs: generic SSL libary failure.
Yep, I'd looked that one up myself quite some time ago. Not very
helpful is it? :P
Now that it's a morning again, I'm going to continue my backwards
trek through the CVS tree until I find a copy that stops leaking. Then
I'll do a diff and find out what changed. Thanks for all of your help
so far (you too Aarno, Alex and Paul)! :)
don't need a diff, simply pass us the date/time mark. That's enough, so we
can
create the diffs on our own. (No reason to distribute the diffs accross the
mailing list for it).
We definetly have to get control on this fd leaking here. I'll mark this as
showstopper for 1.4.1 stable.
Stipe
mailto:stolj_{at}_wapme.de
-------------------------------------------------------------------
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
-------------------------------------------------------------------
