logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael CATANZARITI <mca...@free.fr>
Subject Re: Memory Leaks in Log4cxx
Date Tue, 27 Jul 2004 14:05:46 GMT
I think it's the same problem.
By using the _CRTDBG_REPORT_FLAG flag, it should work.

Michaƫl

Selon Christophe de VIENNE <cdevienne@alphacent.com>:

> Hi,
>
>
> FabijanicA@nucorsteel.com wrote:
>
> >There are 13 memory leaks and 7 resource leaks reported at the end of
> >execution. I am still trying to figure out most of them, but here's where
> >some of the leaks reported are coming from:
> >
> >timezone.cpp      line 32 [2 leaks - calling tzset and gmtime]:
> >TimeZonePtr TimeZone::defaultTimeZone = new TimeZone(_T(""));
> >
> >
>
> gmtime returns a "struct tm *", which is, refering to the man page :
>
> "The return value points to a statically allocated struct which might be
> overwritten by subsequent calls to any  of  the  date  and  time
> functions."
>
> This struct is probably allocated at the first call to gmtime, and then
> never freed.
> I guess the tzset leak has the same reason.
>
> This is for the glibc version of those functions thought. If their win32
> equivalent return dynamically allocated memory, then the code needs to
> be patched to free the memory.
>
> >timezone.cpp      line 92 [1 leak - calling putenv]:              return
> >new TimeZone(ID);
> >
> >
>
> This function alterate the environment. If some memory is allocated I
> don't think it's supposed to be freed.
>
> >tzset(), gmtime() and putenv are all calling malloc()
> >
> >
>
> With my understanding of their behavior (under linux, it may be
> different with the vc++ standard C library), they won't call it each
> time, but rather once for tzset and gmtime, and if needed a few time for
> putenv.
>
> So those leaks are "normal" from the log4cxx point of view, ie we can't
> do anything about it...
>
>
>
> Regards,
>
> Christophe
>



Mime
View raw message