httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: [PATCH] A bug in table adjust function that causes a core dump (fwd)
Date Fri, 10 Jan 2003 11:14:07 GMT
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 <Bernd.Steinert@kippdata.de>
> To: modssl-users@modssl.org
> Cc: jwoolley@apache.org, rse@openpkg.org
> 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: bernd.steinert@kippdata.de
> 

Mime
View raw message