Re: FastCGI dump

Stanley Gambarin (stanleyg@cs.bu.edu)
Thu, 18 Sep 1997 12:37:05 -0400 (EDT)

Date: Thu, 18 Sep 1997 12:37:05 -0400 (EDT)
From: Stanley Gambarin <stanleyg@cs.bu.edu>
To: Stephen Iddings <uiddise@lexis-nexis.com>
Subject: Re: FastCGI dump
In-Reply-To: <199709171354.JAA17448@velma.lexis-nexis.com>
Message-Id: <Pine.GSO.3.96.970918123407.14117B-100000@csa>


	You are correct... the use of if (dynamic == TRUE) is the 
proper solution for this problem.  If you look where the IPC address
gets initialized, you will see that its copied from the existing
server is it's static (since we already know how and where to 
connect to the application).  In the case of the dynamic app, the
IPC address is not known (filled in later by bind/connect) so the
OS_InitIpcAddr() routine is called , which does malloc().  So, there
is your answer... The code should be adjusted to reflect the change.

							Stanley.

On Wed, 17 Sep 1997, Stephen Iddings wrote:

> 
> Stanley wrote,
> 
> >	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())						
> 
> >>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.
> 
> Without going to far into the code we were able to track the problem down further.  We found that the program was dumping in :
> 
> FastCgiHandle()
>   OS_FreeIpcAddr(ipcAddrPtr) 
>      DStringFree(&ipcAddrPtr->bindPath)
>        free(dsPtr->string)
> 
> It appeared that an attempt was being made to free up uninitialized, or static memory.  Examining the code in FastCgiHandle() we came up with a temporary work around:
> 
> ConnectionErrorReturn:
>     msg = (char *) strerror(errno);
>     if (msg == NULL) {
>         msg = "errno out of range";
>     }
>     Free(infoPtr->errorMsg);
>     if(dynamic==TRUE) {           /* added by l-n */
>       OS_FreeIpcAddr(ipcAddrPtr);
>     }
>     infoPtr->errorMsg = Malloc(FCGI_ERRMSG_LEN + strlen(msg));
>     sprintf(infoPtr->errorMsg,
>             "mod_fastcgi: Could not connect to application,"
>             " OS error '%s'", msg);
> 
>  All of our FCGI apps are being ran in static mode for these tests.  Should this call to OS_FreeIpcAddr(ipcAddrPtr) be linked to (dynamic == TRUE)?
> 
> Thanks,
> Steve 
> 
>