Re: your mail

Stanley Gambarin (stanleyg@cs.bu.edu)
Mon, 15 Sep 1997 23:30:17 -0400 (EDT)

Date: Mon, 15 Sep 1997 23:30:17 -0400 (EDT)
From: Stanley Gambarin <stanleyg@cs.bu.edu>
To: Stephen Iddings <uiddise@lexis-nexis.com>
Subject: Re: your mail
In-Reply-To: <199709151613.MAA10138@velma.lexis-nexis.com>
Message-Id: <Pine.GSO.3.96.970915232618.17526A-100000@csa>


	This indeed looks like a problem... From your output 
it seems that FCGIHandler is passing a null pointer to the
BufferDelete routines.  Is the problem reproducible under
other OS, os is it specific to Solaris.  Also, do you have
any error messages in your logfile (which should help track
down the problem). Finally, if it possible for you, can you
track down exactly whihc BufferDelete call it croaks on ,
there are 4 right now ( in FCGICleanup()).

						Stanley.
On Mon, 15 Sep 1997, Stephen Iddings wrote:

> We are currently using FastCGI 2.0b1 with Apache 1.2.1 on Solaris 5.5.1 and we are experiencing a core dump.  It appears that if the number of requests for a FastCGI application exceeds the listen-queue-depth that the application returns a HTTP 500 (Internal Server Error) and then core dumps.  Here's the stack from dbx, it may or may not be informative:
> 
> (dbx) where
> =>[1] _kill(0x0, 0x6, 0x0, 0x0, 0xffffffff, 0x9a340), at 0xef5f4340
>   [2] abort(0x0, 0x9c410, 0x7d1a0, 0x97f80, 0x0, 0x1), at 0xef5ba5e0
>   [3] seg_fault(0xb, 0x0, 0xeffff040, 0x0, 0x0, 0x0), at 0x1ea00
>   ---- called from signal handler with signal 11 (SIGSEGV) ------
>   [4] BufferCheck(), at 0x61aa4
>   [5] BufferDelete(0x0, 0xb8, 0xef61574c, 0xb2af0, 0xeffff424, 0xa57e8), at 0x61f58
>   [6] FcgiCleanUp(0xa59c8, 0xb2af0, 0xb14d8, 0x7efefeff, 0x81010100, 0xff00), at 0x6d8e4
>   [7] FastCgiHandler(0xb14d8, 0x9751d, 0x3b000000, 0x0, 0xef5facec, 0x0), at 0x6eca8
>   [8] invoke_handler(0xb14d8, 0x7e3b4, 0x0, 0x0, 0x10, 0x10), at 0x28868
>   [9] process_request_internal(0xb14d8, 0xeffff7a8, 0x0, 0x0, 0x0, 0xef650384), at 0x2f71c
>   [10] process_request(0xb14d8, 0x4, 0xb14d8, 0xeffff824, 0xeffff834, 0x5), at 0x2f7a8
>   [11] child_main(0x5, 0x1ea38, 0x0, 0xef616cfc, 0xeffff894, 0x0), at 0x205f0
>   [12] make_child(0x9c410, 0x5, 0xffffffff, 0x9e400, 0x3, 0xeffff939), at 0x209d0
>   [13] standalone_main(0x5, 0xeffffa34, 0x9a340, 0x36353400, 0x2f, 0x9a340), at 0x21764
>   [14] main(0x5, 0xeffffa34, 0xeffffa4c, 0x99c00, 0x1, 0x0), at 0x2211c
> (dbx) 
> 
> We realize that we can adjust the number of FCGI applications we launch or/and the listen-queue-depth, however, this may become unacceptable. Is this a known problem?  Is there a patch?  Is there a plan to fix this?  
> 
> Also, is there a maximum limit on the -listen-queue-depth?
> 
> Thanks,
> Steve 
>