Hi, It appears that I had to "clean" the project, only then did this method work, thanks Fabian.
On Mon, Dec 13, 2010 at 2:43 PM, Fabian Jacquet <fabian.jacq...@gmail.com> wrote: > Are you sure that log4cxx is loaded after MFC? > You can check it with the "/VERBOSE:LIB" option of the linker. > > On Sun, Dec 12, 2010 at 11:50, Noam Rathaus <no...@beyondsecurity.com> > wrote: >> >> Hi, >> I tried your method, it didn't go away :( >> I even verified that it was looking at my ignore list but not adding back >> log4cxx... >> Any other pointers? >> >> 2010/10/27 Fabian Jacquet <fabian.jacq...@gmail.com> >>> >>> 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-yamaw...@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. >>>>> >>>>> -cory >>>>> >>>>> >>>>> 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-yamaw...@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() >>>>>> { >>>>>> CDialog::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; >>>>>> } >>>>>> >>>>>> thanks, >>>>>> Kenichi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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. >>>> E-mail:k-yamaw...@carinasystem.co.jp >>>> TEL +81-78-954-5231 >>>> >>> >> > >