On Thu, Jan 09, 2003 at 11:49:39AM -0500, Cliff Woolley wrote: > > Can anyone comment on this?
shmht in 2.0 is quite unstable, there are several bugs in the table code like the one below (and some more nasty, like an off-by-one overflow) most of which are fixed in later versions of mod_ssl 2.8. Additionally the conversion of _shmht.c to the RMM API wasn't completed - it breaks as the apr_rmm_*alloc functions return zero when the segment is full. In my testing, shmht still wasn't stable under moderate SSL load even with all the above fixed. I just removed it from our httpd package - shmcb is really the session cache of choice and there's little reason to use shmht these days. > > --Cliff > > ---------- Forwarded message ---------- > Date: Thu, 09 Jan 2003 13:48:59 +0100 > From: Bernd Steinert <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: [PATCH] A bug in table adjust function that causes a core dump > > On Thursday, 5 December 2002, Cliff Wooley replied: > > > On Thu, 5 Dec 2002, Bernd Steinert wrote: > > > > > on November 11 Kirill Shirkov reported a bug in the table_adjust function > > > that causes core dumps. He described how the core dumps can be reproduced. > > > Some colleague of mine confirmed this behaviour. > > > > I must have missed the patch... can someone repost it for me (and CC: me > > and Ralf on it), and put [PATCH] at the beginning of the subject line of > > the message. > > Thanks a lot Cliff for the immediatereply. (unfortunaltely I missed it > before going > on holidays.) > > Here is what Kirill Shirkov wrote on Friday, November 11, 2002 --- his fix > is at the end: > > > Hi folks, > > > > I have found a bug in table_adjust function, and I haven't seen any > reports about > > this error in the mailing list. Also, this error is not fixed in the > current version > > of mod_ssl (2.8.12). > > > > THE BUG > > ------------- > > > > ssl_util_table.c file, line 1755: > > > > buckets = (table_entry_t **) table_p->ta_calloc(buck_n, > sizeof(table_entry_t *)); > > if (table_p->ta_buckets == NULL) > > return TABLE_ERROR_ALLOC; > > > > buckets variable is not checked here and this causes a coredump when the > table size > > is big and there is no memory for reallocating the buckets. Below is a > stack dump > > from Solaris 8 running Apache 1.3.26 + mod_ssl 2.8.10 + OpenSSL 0.9.6g: > > > > ... > > --- called from signal handler with signal 11 (SIGSEGV) --- > > 00089b60 table_adjust (0, fe0a09cc, fe09ea84, 0, 3e9, fe08cdd8) + d0 > > 00081cac ssl_scache_shmht_expire (1, 20, fe0e436c, 4, 31, fe08e438) + 130 > > 00081a24 ssl_scache_shmht_store (94, 18aef0, 20, bb8200, bb81b8, 1ad4e0) > + 11c > > 0007b7e0 ssl_callback_NewSessionCacheEntry (bb8200, 3dc42bfb, 7b784, > 1ad4e0, bb81b8, ba65e0) + 5c > > fe64c584 ssl_update_cache (a1c458, 2, 21c1, 1ad4e0, 1, a1c458) + a8 > > fe63ef14 ssl3_accept (a1c458, 2100, 21c0, 3004, 90, 0) + 8c8 > > fe64d520 SSL_accept (a1c458, fe63e64c, 1, ba1088, 10, ba109a) + 24 > > fe648d94 ssl23_get_client_hello (2a, 70, 2, ffbef100, 1, a1c458) + 7cc > > fe648528 ssl23_accept (a1c458, fe648388, 1a1f70, 0, 6f757400, 6f757400) > + 1a0 > > fe64d520 SSL_accept (a1c458, 79d30, 12c, 0, 16fab0, 17cee0) + 24 > > 00079730 ssl_hook_NewConnection (908cc0, 178000, 1781d0, ffbef2cc, > 16fa34, 806478) + 2b4 > > 0004c4a0 new_connection (163b1c, 45415049, 908cc0, ffbef344, ffbef344, > 3) + 114 > > 0004d470 child_main (173400, 173400, 173400, ff36b228, ff365958, > ff35efb8) + 634 > > ... > > > > HOW TO REPRODUCE > > ---------------------------------- > > > > I was able to reproduce the error in the following way: > > > > 1. Set SSLSessionCacheTimeout to 20 minutes > > 2. Set SSLSessionCache size to 1024000 (or a value that is close to your > EAPI_MM_CORE_MAXSIZE). > > 3. Set ExtendedStatus to On > > 4. Start the server and run a script like the following one: > > > > #!/usr/local/bin/bash > > > > i=0 > > while expr $i \< 400 >/dev/null; do > > echo $i > > i=`expr $i + 1` > > > > for j in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do > > curl -I https://your.host/ & > > done > > sleep 1 > > done > > > > BTW, you may interrupt the script when the "current sessions" parameter > at the bottom > > of the server status page (https://your.host/server-status) have stopped > growing. > > > > 5. Wait 25 minutes from the time you have started the script and reload > the server > > status page or access the server over SSL. Most likely you will see a > core dump. > > > > THE FIX > > ------------ > > > > If we change the if statement like this:.. > > > > if (table_p->ta_buckets == NULL || buckets == NULL) > > return TABLE_ERROR_ALLOC; > > > > ...the server doesn't dump core in the test. > > > > Another solution to this problem is to decrease shared memory size in > the config file. > > > > Best regards, > > Kirill Shirokov, > > St. Petersburg, Russia. > > > --- > Dr. Bernd Steinert > kippdata GmbH Tel.: 0228 - 9 85 49 0 > Bornheimer Str. 33a Fax: 0228 - 9 85 49 50 > D-53111 Bonn eMail: [EMAIL PROTECTED] >
