Fine :-)
On Tue, Dec 14, 2010 at 12:41, Noam Rathaus <no...@beyondsecurity.com>wrote:
> 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<e-mail%3ak-yamaw...@carinasystem.co.jp>
> >>>> TEL +81-78-954-5231
> >>>>
> >>>
> >>
> >
> >
>
