On Thu, May 13, 2010 at 4:43 AM, Ruediger Pluem <[email protected]> wrote:
> On 10.05.2010 22:47, [email protected] wrote:
>> Author: trawick
>> Date: Mon May 10 20:47:59 2010
>> New Revision: 942897
>>
>> URL: http://svn.apache.org/viewvc?rev=942897&view=rev
>> Log:
>> prefork MPM: Run cleanups for final request when process exits gracefully.
>> PR: 43857
>> Submitted by: Tom Donovan, simplified slightly by me
>>
>> Modified:
>>     httpd/httpd/trunk/CHANGES
>>     httpd/httpd/trunk/server/mpm/prefork/prefork.c
>>
>> Modified: httpd/httpd/trunk/CHANGES
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=942897&r1=942896&r2=942897&view=diff
>> ==============================================================================
>> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
>> +++ httpd/httpd/trunk/CHANGES [utf-8] Mon May 10 20:47:59 2010
>> @@ -28,6 +28,9 @@ Changes with Apache 2.3.7
>>       processing is completed, avoiding orphaned callback pointers.
>>       [Brett Gervasoni <brettg senseofsecurity.com>, Jeff Trawick]
>>
>> +  *) prefork MPM: Run cleanups for final request when process exits 
>> gracefully.
>> +     PR 43857.  [Tom Donovan, Jeff Trawick]
>> +
>>    *) ab: fix number of requests sent by ab when keepalive is enabled.  PR 
>> 48497.
>>       [Bryn Dole <dole blekko.com>]
>>
>>
>> Modified: httpd/httpd/trunk/server/mpm/prefork/prefork.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/prefork/prefork.c?rev=942897&r1=942896&r2=942897&view=diff
>> ==============================================================================
>> --- httpd/httpd/trunk/server/mpm/prefork/prefork.c (original)
>> +++ httpd/httpd/trunk/server/mpm/prefork/prefork.c Mon May 10 20:47:59 2010
>> @@ -549,12 +549,6 @@ static void child_main(int child_num_arg
>>          conn_rec *current_conn;
>>          void *csd;
>>
>> -        /*
>> -         * (Re)initialize this child to a pre-connection state.
>> -         */
>> -
>> -        apr_pool_clear(ptrans);
>> -
>
> Doesn't this create a memory leak? Don't we need to reset this pool for every
> new connection?

This original commit had a potential leak when apr_socket_accept()
failed, but it did clear the pool at the end of handling a
successfully-accepted connection.  The final commit should handle
either situation.

Reply via email to