I found the culprit.  The EOS bucket was being removed from the brigade but not destroyed.  I'm going to submit the following patch to fix this bug.

 

*** proxy_http_old.c Tue Dec  9 16:19:52 2003

--- proxy_http.c Tue Dec  9 16:22:14 2003

***************

*** 665,671 ****

              }

 

              /* We can't pass this EOS to the output_filters. */

!             APR_BUCKET_REMOVE(APR_BRIGADE_LAST(bb));

              seen_eos = 1;

          }

 

--- 665,672 ----

              }

 

              /* We can't pass this EOS to the output_filters. */

!             e = APR_BRIGADE_LAST(bb);

!             apr_bucket_delete(e);

              seen_eos = 1;

          }

 

Thanks,

Larry.

 

-----Original Message-----
From: Larry Toppi [mailto:[EMAIL PROTECTED]]
Sent
:
Monday, December 08, 2003 6:57 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Mem Leak when reverse proxying HTTP post requests

 

I did a little more debugging into this one and it seems that for every HTTP POST request that gets reverse proxied, we lose a mem block from the bucket allocator list which eventually causes the apr_bucket_alloc() code to invoke malloc().  This leak only happens if there is data in the request body that gets POST'ed.  Eg. UserName=user1

 

I've opened up a bugzilla bug report, #24991.  Any insights or clues to help track this down would be very much appreciated.

 

Thanks,

Larry.

 

-----Original Message-----
From: Larry Toppi [mailto:[EMAIL PROTECTED]
Sent:
Wednesday, December 03, 2003 12:41 PM
To: '[EMAIL PROTECTED]'
Subject: Mem Leak when reverse proxying HTTP post requests

 

Hi,

 

I'm running the JMeter stress test tool to create HTTP POST requests through Apache (v.2.0.48) on the Windows 2000 platform.  The request posts a small amount of data to a web page.  Apache is configured to reverse proxy (ProxyPass) the request to the backend web server.  In doing so, it seems that Apache leaks memory.  Has anyone seen this or knows why this is happening?  This memory leak does not happen when reverse proxying HTTP GET requests.

 

Thanks,

Larry.

Reply via email to