You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by Curt Arnold <ca...@apache.org> on 2006/04/01 07:20:06 UTC

Re: possible memory leak with syslog feature in log4cxx-0.9.8.tar.gz?

On Mar 31, 2006, at 1:19 PM, Min Tjong wrote:

> Hello,
>
>
>
> First of all, I apologize for this rather lengthy email.  I am new  
> to log4cxx and have recently encountered a memory leak issue with  
> log4cxx-0.9.8.tar.gz.  I downloaded it fromhttp:// 
> littletux.homelinux.org/log4cxx and started playing with the syslog  
> feature
>
> by modifying the console example code provided in the package.    
> Basically the configure function is modified to use SyslogAppender  
> and PatternLayout and the main function is modified to include a  
> while loop with a sleep statement between logging occurrences.  The  
> entire modified code is presented below.
>
>
>
> Running the program on Windows XP, I am experiencing a memory leak  
> of approximately 120 bytes on each logging occurrence.
>
> I wonder if anybody has experienced something similar to this?   
> After some investigation, I found out that the leak was caused by  
> the call to apr_sockaddr_info_get in the DatagramSocket::send 
> (DatagramPacketPtr& p) method (datagramsocket.cpp).  At this point  
> I wonder if I am missing something.  Any comment/help would be much  
> appreciated.
>
>
>
> Regards,
>
> Min

The implementation of DatagramSocket::send does not correspond to the  
source in the Apache SVN (http://svn.apache.org/viewcvs.cgi/logging/ 
log4cxx/trunk/src/datagramsocket.cpp?rev=308840&view=markup).  I  
assume the author intended to commit the code, but somehow it fell  
through the cracks and it only appears in the littletux tarball.

 From the fragment, it appears that DatagramSocket has a member  
variable named memoryPool of type log4cxx::helpers::Pool.  Memory  
allocated from that pool is not reclaimed until the pool is destroyed  
which explains the observed memory leakage.  I would recommend that  
the member variable be removed and a Pool& be passed as a parameter  
to the send function (and another other function that needs a memory  
pool).