Memory Leak with MFC

["山脇健一(Yamawaki Kenichi)"]

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

[Griffiths, Patrick]

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@...]
Sent: Wednesday, November 04, 2009 5:23 PM
To: log4cxx-user@...
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.

[Cory Riddell-3]

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@...]
> Sent: Wednesday, November 04, 2009 5:23 PM
> To: log4cxx-user@...
> 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.
>
>
>  

["山脇健一(Yamawaki Kenichi)"]

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@...]
>> Sent: Wednesday, November 04, 2009 5:23 PM
>> To: log4cxx-user@...
>> 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@...
TEL [phone]