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.
Ron
-----Original Message-----
From: Norman Tuttle [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 2:17 PM
To: [email protected]
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, [EMAIL PROTECTED]
PS Question: how many similar issues exist in the current state of the APR?
