Whenever somebody visits a page in https region of my server, (using basic password authentication), one of the httpd processes on the server goes into an infinite loop, pegged at 100% CPU. I've tracked the problem down to the loop in ssl_io_input_getline at about line 704 in ssl_engine_io.c. It appears that there are circumstances in which SSL_read on an ssl stream can persistenly return 0. The code in ssl_io_input_getline doesn't recognize 0 as an error, so it just keeps trying, forever, in an infinite loop. I'm using openssl 0.9.6c. The man page for SSL_read is--shall we say-- challenging, so I'm not sure whether this "persistent 0" behavior is a bug or a feature, but it is quite repeatable in my setup. When it occurs, SSL_get_error returns SSL_ERROR_ZERO_RETURN. Fortunately, there's a one-line fix to ssl_io_input_getline: while (tmplen > 0) { status = ssl_io_input_read(ctx, buf + offset, &tmplen); if (status != APR_SUCCESS) { return status; } if (tmplen == 0) break; /* <---- add this line */ *len += tmplen; I can't be sure this isn't simply plastering over some more serious problem, but it seems to work for me. If you need any additional info (version of solaris, httpd.conf file, phase of the moon ...) just ask.
A similar fix was made by dougm into ssl_io_input_read to return APR_EOF when OpenSSL returns 0. (This is one of the major gotchas we found right after releasing 2.0.35.) This fix is in modules/ssl/ssl_engine_io.c revision 1.73. It will be included in the next release of Apache. Thanks for using Apache!
It would be nice if "major gotchas" were documented somewhere on the web page to save poor slobs like me from wasting a whole day tracking down the bug only to be told "oh yeah, we knew that".
Well, sorry about that. The best thing we can recommend is to search resolved bugs or download our latest CVS snapshots. Unfortunately, Bugzilla doesn't default to searching closed bugs. We are intending to do a 2.0.36 release in the next few days to address the PRs that we have already fixed (and it's been a bunch). Thanks for using Apache!
To add to what Justin said (since he and I were saying it at the same time and he beat me to it ;), if you suspect a bug, the best thing to do is always to check the CHANGES file in the development tree (http://cvs.apache.org/viewcvs.cgi/httpd-2.0/CHANGES)... that's our central repository of Things We've Fixed. The STATUS file in that same directory is also a good place to look, as it might mention known but outstanding issues. Thanks...
I did indeed search the bug database before launching into my own search of the source code. I just tried again. Keyword searches always come up empty. I finally tried searching all bugs involving mod_ssl in 2.0.35 in all states, and found out that my bug was a duplicate of 8165, which is listed as CLOSED (what's the difference between CLOSED and RESOLVED?) As for searching http://cvs.apache.org/viewcvs.cgi/httpd-2.0/CHANGES , I'm afraid that useless. The CVS check-in message associated with the fix of that bug is, in its entirety, PR: 7802 Obtained from: Submitted by: Reviewed by: fix compilation problem in ssl_engine_kernel.c if SSL_LIBRARY_VERSION >= 0x00907000
Don't look at the commit log for CHANGES, look at the contents of CHANGES itself. What I was trying to get you to see was this in particular, though: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/CHANGES.diff?r1=1.689&r2=1.690 When you go to http://cvs.apache.org/viewcvs.cgi/httpd-2.0/CHANGES, you have to click on the version number of the most recent revision to see the file itself. Thanks again.