Stipe,
which IPs do you mean Jonathan? The client (WAP device) IPs? I guess you would have them in the wapaccess.log file logged. I'm not sure (without code review) if "broken requests" are logged in wapaccess.log, but I guess not.
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, 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.
This may be also reproducable, right?
Yeppers, at least on my box. :)
Ok, but this does not clear-up the fact that your 2004-11-05 version seems to "not" leak any fds?
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.
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)! :)
Jon
