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<e-mail%3ak-yamaw...@carinasystem.co.jp> >>> TEL +81-78-954-5231 >>> >>> >> >
