httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: memory leak on daedalus
Date Tue, 17 Jul 2001 19:55:31 GMT
Greg Ames wrote:
> 
> Brian e-mailed me earlier today because he noticed the httpd processes on
> daedalus were starting to grow.  They were up to around 10-12M when he
> noticed it, so he restarted the server.

We were back up to 10M per process with MaxRequestsPerChild at 400, so I
bounced the server back to the old 2.0.16 build at 08:58:10 PDT.  The
old build is running fine as far as memory usage.

Digging thru the core dump from the new build, I see we are leaking
apr_sockaddr_t's.  They are being allocated out of the pconf pool, so
they will never be cleaned up until the process dies due to
MaxRequestsPerChild (which can take a lot longer than you might think
with HTTP/1.1) or ap_perform_idle_server_maintenance.  I don't know yet
which piece of code is doing this, so feel free to beat me to it.  

There's other leaked stuff I don't recognize yet, but if we solve the
apr_sockaddr_t problem, the rest will probably fall out for free.

Greg

gory details:

here's some leaked stuff from
/usr/local/apache2.0.21-dev/corefiles/httpd.core.fat

(gdb) x/100xw 0x8700000
0x8700000:      0x00000000      0x00000000      0x00000000     
0x00000000
0x8700010:      0x00000000      0x00000010      0x00000004     
0x00000010
0x8700020:      0x086ffffc      0x00000000      0x00000000     
0x086fff6c
0x8700030:      0x08085f2c      0x08089d7c      0x082b0964     
0x080c000c
0x8700040:      0x08700084      0x00000000      0x00000050     
0x00000002
0x8700050:      0x50000210      0x0100007f      0x00000000     
0x00000000
0x8700060:      0x00000000      0x00000000      0x00000000     
0x00000010
0x8700070:      0x00000004      0x00000010      0x08700054     
0x00000000
0x8700080:      0x00000000      0x2e373231      0x2e302e30     
0x00000031
0x8700090:      0x00000000      0x080c000c      0xffffffff     
0x00000001
0x87000a0:      0x087000c4      0x0870003c      0x002dc6c0     
0x00000000
0x87000b0:      0x00000001      0x00000001      0x00000020     
0x00000000
0x87000c0:      0x00000000      0x080c000c      0x00000000     
0x00000000
0x87000d0:      0x00000000      0x00000002      0x00000200     
0x00000000
0x87000e0:      0x00000000      0x00000000      0x00000000     
0x00000000
0x87000f0:      0x00000000      0x00000010      0x00000004     
0x00000010
0x8700100:      0x087000dc      0x00000000      0x00000000     
0x080c000c
0x8700110:      0x00000000      0x00000000      0x00000000     
0x00000002
0x8700120:      0x00000200      0x00000000      0x00000000     
0x00000000
0x8700130:      0x00000000      0x00000000      0x00000000     
0x00000010
0x8700140:      0x00000004      0x00000010      0x08700124     
0x00000000
0x8700150:      0x00000000      0x08700094      0x08085f2c     
0x08089d7c
0x8700160:      0x082b0964      0x080c000c      0x087001ac     
0x00000000
0x8700170:      0x00000050      0x00000002      0x50000210     
0x0100007f
0x8700180:      0x00000000      0x00000000      0x00000000     
0x00000000

there's an apr_sockaddr_t starting at 0x870003c, another at 0x8700164. 
(hmmm, both of these offset 4 bytes from an 8 byte boundary). 
0x080c000c is the pconf pool.  starting at 0x8700084 is the string
"127.0.0.1" - localhost.  0x00000050 == 80, our port.  0x00000002 is the
address family.

there's another repeating pattern at 0x8700010, 0x8700068, 0x87000f0,
and 0x8700138 which goes <0, 16, 4, 16, (ptr to a few bytes before
this), 0, 0, ptr>.  I don't know what this is.  We shouldn't need to
figure out what it is to solve this problem, but if you have any ideas,
please speak up.  It might come in handy in the future.

Mime
View raw message