apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Tuttle <ntut...@opendemand.com>
Subject Re: Bug found in APR sockets while trying to properly memory-manage Flood-based project
Date Mon, 17 Nov 2003 23:34:22 GMT
For load test software or some other real heavy socket-users it could be 
significant. In my specific application, I want to separate the pools, 
but in the case of keep-alive sockets, memory must be allocated out of 
pools that stay around longer than on the per-request timeframe. My 
whole issue is that the software is causing the application to gobble up 
memory at high load too quickly (especially if running for a significant 
amount of time), so I need to tighten up the pool management.

-Norman Tuttle, developer, OpenDemand Systems, ntuttle@opendemand.com

Ron Park wrote:

>Although I don't believe this is a memory leak (because it's alloced
>out of the same pool and hence will be cleaned up when the socket is),
>the lack of memcpy at line 300 of sockets.c is a concern.  Consider
>the case where 'sa' is alloced from a pool with a shorter lifespan
>than the pool for the socket... potential kaboom.  This is probably
>never a problem for most code ('sa' is likely alloced from a pool
>that has a lifetime of the process or at least the request where
>socket is alloced) but some odd code could leave cause a problem.
>-----Original Message-----
>From: Norman Tuttle [mailto:ntuttle@opendemand.com] 
>Sent: Monday, November 17, 2003 2:17 PM
>To: dev@apr.apache.org
>Subject: Bug found in APR sockets while trying to properly memory-manage Flood-based project
>While trying to memory-tune code which we are working on based on Apache 
>Flood, an apr project, I noticed some potentially memory-leak prone 
>code. While alloc_socket() called by apr_socket_create() does an 
>apr_palloc() to allocate memory for a socket's remote_addr member, the 
>apr_socket_connect() function sets the remote_addr directly to the 
>apr_sockaddr_t * which it passes. The problem is that that defeats the 
>purpose of allocating a buffer for it, since you're replacing with a new 
>pointer which presumably also had to allocate its space (and the typical 
>apr_socket_addr_get() would do that). So we need to use a memcpy() instead!
>-Norman Tuttle, developer, OpenDemand Systems, ntuttle@opendemand.com
>PS Question: how many similar issues exist in the current state of the APR?

View raw message