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 Noam Rathaus <no...@beyondsecurity.com> on 2010/12/12 11:50:29 UTC
Re: Memory Leak with MFC
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 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
>>>
>>>
>>
>