David MacDonald
asked on
Memory leaks... on a CDialog
Hi all,
just want to know if any of you are familiar with this memory leak :
I just open my Dialog and close it...
Detected memory leaks!
Dumping objects ->
{41} client block at 0x004925D0, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $004925D0, 64 bytes long
a CDynLinkLibrary object at $004925D0, 64 bytes long
Object dump complete.
Wow, how fun... :)
just want to know if any of you are familiar with this memory leak :
I just open my Dialog and close it...
Detected memory leaks!
Dumping objects ->
{41} client block at 0x004925D0, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $004925D0, 64 bytes long
a CDynLinkLibrary object at $004925D0, 64 bytes long
Object dump complete.
Wow, how fun... :)
r u using dll's?
is your CDialog of the heap, if so delete it when you are finished with it
CDialogDerived *dd = new CDialogDerived();
dd->DoModal();
delete dd;
hopet this helps
CDialogDerived *dd = new CDialogDerived();
dd->DoModal();
delete dd;
hopet this helps
ASKER
Yes, i'm using 2 dll's ... but double-clik not working
The Dlg is on the frame...
the dll's are loaded direct at the start... maybe they are the cause.... hmmmm...
Ok ... i'll try to look for a leak in the dll's... i'll keep you posted...
The Dlg is on the frame...
the dll's are loaded direct at the start... maybe they are the cause.... hmmmm...
Ok ... i'll try to look for a leak in the dll's... i'll keep you posted...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I agree with zoppo not all leaks reported are actually leaks
to test this put a breakpoint on the constructor of CDynLink and write down the address
then put a break point in the destructor and see if it is called with the correct address of the original object - if the destructor is being called but it is still reporting as a leak then it is a 'feature' of the leak reporting.
This is made easier obviously if you only have 1 CDynLinkLibrary being created (1 per DLL) adn if it stays at the same allocation number (eg in your case {41} )
to test this put a breakpoint on the constructor of CDynLink and write down the address
then put a break point in the destructor and see if it is called with the correct address of the original object - if the destructor is being called but it is still reporting as a leak then it is a 'feature' of the leak reporting.
This is made easier obviously if you only have 1 CDynLinkLibrary being created (1 per DLL) adn if it stays at the same allocation number (eg in your case {41} )
ASKER
Thanks Zoppo, exactly that...
i'll remember that... you can be sure
i'll remember that... you can be sure
you're welcome...
have a nice day,
regards,
ZOPPO
have a nice day,
regards,
ZOPPO
did u try to dbl-click on the mem-leak line sometimes u get to the line where the memory is leaking