Hi all,

I have those memory leaks too, and after a lot of researches I found a pretty solution.

The real problem is the following. When the process unloads MFC, it checks the memory. But in our case, log4cxx is unloaded after MFC. So every static object of log4cxx is flagged as memory leak.
I found the way to force the linker to unload log4cxx before MFC.

First, you have to activate a property of your exe project: "Configuration Properties/Linker/General/Show Progress" set to "/VERBOSE:LIB"
When you link your software you can see which MFC lib you use. In my case:
2>    Searching log4cxxd.lib:
2>    Searching C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfc80d.lib:
2>    Searching C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib\mfcs80d.lib:
2>    Searching C:\Program Files\Microsoft Visual Studio 8\VC\lib\msvcrtd.lib:

MSVCRTD.lib is not part of MFC but must be loaded after MFC so we must be careful about this.
Note that log4cxxd.lib is linked before MFC and so is loaded before and unloaded after.

Now we can change this order. In the property of the software "Configuration Properties/Linker/Input"
In the field "Ignore Specific Library", add this: "log4cxxd.lib;mfc80d.lib;mfcs80d.lib;msvcrtd.lib" replacing MCF libs with libs you listed above.
Then add those libs in the field "Additional Dependencies" in the good order. In my case: "mfc80d.lib mfcs80d.lib msvcrtd.lib log4cxxd.lib"

If you link again you can see that log4cxxd.lib is linked after MFC and normally you have no more memory leak.

I hope it helps you.

On Mon, Nov 9, 2009 at 02:48, Yamawaki Kenichi <k-yamawaki@carinasystem.co.jp> wrote:
thanks Patrick, Cory,

I've understood that these are not memory leak.
They are side effects of ordering of destruction.
and I ran my sample program 3 times.
the allocation numbers are consistent.

Patrick is right. Run it a few times and see if the allocation numbers
change (124, 1151, and 1152). If you can get it to repeat consistently,
set a breakpoint at those allocations to see what it is that's leaking.

You could also rebuild using the debug version of new. That way, you
will get file and line numbers in the memory dumps.


Griffiths, Patrick wrote:
This doesn't show that the leak is or is not log4cxx.

Keep in mind that log4cxx uses static singleton objects. It's quite possible that what you are seeing is a simply a side effect caused by the ordering of the destruction of static objects.

-----Original Message-----
From: "ɽ|һ(Yamawaki Kenichi)" [mailto:k-yamawaki@carinasystem.co.jp]
Sent: Wednesday, November 04, 2009 5:23 PM
To: log4cxx-user@logging.apache.org
Subject: Memory Leak with MFC

Hi Exparts,

I use the log4cxx-0.10.0.
I made below programs with MFC. Then I have faced a certain memory leak.
Please teach the method of settlement.

// leak version (with MFC)
BOOL CLogTestDlg::OnInitDialog()
       LoggerPtr       logger = Logger::getLogger( "test" );
       return TRUE;

Detected memory leaks!
Dumping objects ->
{1152} normal block at 0x01B08818, 56 bytes long.
 Data: <0 n 0 n 0 n     > 30 F1 6E 02 30 F1 6E 02 30 F1 6E 02 00 00 00 00
{1151} normal block at 0x01B08768, 116 bytes long.
 Data: <Lb  db   -n     > 4C 62 1D 10 64 62 1D 10 8C 2D 6E 02 00 00 00 00

   -----Omission ------

{124} normal block at 0x01B02218, 52 bytes long.
 Data: < P   l  P       > C8 50 B0 01 90 6C B0 01 50 BA B0 01 CD CD CD CD

// A program without MFC doesn't leak memory.
int _tmain(int argc, _TCHAR* argv[])
       LoggerPtr       logger  = Logger::getLogger("test");
       return 0;


This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.


Kenichi Yamawaki
carina system co.,ltd.
TEL +81-78-954-5231