Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-Id: <sc10cfd3.000@prv-mail20.provo.novell.com>
Date: Fri, 07 Dec 2001 14:19:53 -0700
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <dev@httpd.apache.org>
Subject: Declaring large stack variables...
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

   It appears that we are running into the same problem with Apache 2.0
that we had with Apache 1.3.  The problem is recursive functions that
declare large stack variables such as:

static int read_type_map(apr_file_t **map, negotiation_state *neg,
request_rec *rr)
{
    request_rec *r = neg->r;
    apr_file_t *map_ = NULL;
    apr_status_t status;
    char buffer[MAX_STRING_LEN];           <------------ resolves to
8192
    enum header_state hstate;
    struct var_rec mime_info;
    int has_content;

    if (!map)
        map = &map_;


Now I know that the above function is not directly recursive, but it
could still be called several times within the same code path chewing up
8k each time.  

    Unlike many other platforms, NetWare does not have growable stacks.
 When a thread is started, it is given a stack size.  If that stack size
is exceeded, bad things happen.  Declaring large stack variables aren't
normally a problem except when used in recursive functions.  It doesn't
take many recursive calls with each call allocating an 8k stack variable
before you blow a 64k stack (which is our default for apache).  This
isn't a problem in APR where I can just do things the "NetWare" way, but
HTTPD is a different story.  Is there any way that we can avoid
allocating large stack variables or at least minimize it.  Allocating
buffers as in the above code seems to be a common occurrance in Apache. 
I haven't yet had the time to indentify all of the potential problem
spots in the code, but I will as we get into more stress testing.  Until
then I just wanted to point out this problem and I don't see a good way
to fix it given the HTTPD architecture.

Any ideas?

Brad