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
>>>> TEL +81-78-954-5231
>>>>
>>>
>>
>
>

Reply via email to