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 >> >> >
