You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by Fabian Jacquet <fa...@gmail.com> on 2010/10/27 11:12:15 UTC
Re: Memory Leak with MFC
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.
>>
>> -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-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()
>>> {
>>> 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-yamawaki@carinasystem.co.jp<E-...@carinasystem.co.jp>
> TEL +81-78-954-5231
>
>
Re: Memory Leak with MFC
Posted by Fabian Jacquet <fa...@gmail.com>.
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
> <fa...@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 <fa...@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-...@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-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()
> >>>>>> {
> >>>>>> 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-yamawaki@carinasystem.co.jp<E-...@carinasystem.co.jp>
> >>>> TEL +81-78-954-5231
> >>>>
> >>>
> >>
> >
> >
>
Re: Memory Leak with MFC
Posted by Noam Rathaus <no...@beyondsecurity.com>.
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
<fa...@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 <fa...@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-...@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-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()
>>>>>> {
>>>>>> 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-yamawaki@carinasystem.co.jp
>>>> TEL +81-78-954-5231
>>>>
>>>
>>
>
>
Re: Memory Leak with MFC
Posted by Fabian Jacquet <fa...@gmail.com>.
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 <fa...@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-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.
>>>>
>>>> -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-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()
>>>>> {
>>>>> 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-yamawaki@carinasystem.co.jp<E-...@carinasystem.co.jp>
>>> TEL +81-78-954-5231
>>>
>>>
>>
>
Re: Memory Leak with MFC
Posted by Noam Rathaus <no...@beyondsecurity.com>.
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 <fa...@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-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.
>>>
>>> -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-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()
>>>> {
>>>> 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-yamawaki@carinasystem.co.jp<E-...@carinasystem.co.jp>
>> TEL +81-78-954-5231
>>
>>
>