OLE memory leak
Larry Siden -- lsiden@jade.bioimage.com
Tuesday, April 30, 1996
Env: Win 3.11, VC++ 1.50
Problem:
When my program exits, the MFC debug library generates the
following lines in my output window:
Detected memory leaks!
Dumping objects ->
{2} non-object block at $38AF5772, 28 bytes long
{1} non-object block at $38AF5736, 28 bytes long
Object dump complete.
Normally, leaks in MFC are a piece of cake to find. You just break at
the top of WinMain, set _afxBreakAlloc=1 (or 2) and let 'er rip until
it breaks at the requested allocation. The problem is, it never
breaks on allocation # 1 or 2. (I tried setting _afxBreakAlloc=10 and
it works fine!).
I do know that this allocation occurs very early in WinMain or
CWinApp::InitInstance(), perhaps inside AfxOleInit().
The only other hint I have is that 0x38AF happens to be the base of my
stack and local heap (medium model), so this must be a local
allocation.
What other tools can I use to find this sucker?
============================================================================
Larry Siden, Senior Software Engineer phone: 313-930-9900 x211 (w)
Bio Image, Inc.
777 E. Eisenhower Pky, Suite 950 email: (w) lsiden@bioimage.com
Ann Arbor, MI 48108 (h) 73677.1646@compuserve.com
Jeff_Stong@bio-rad.com
Wednesday, May 01, 1996
[Mini-digest: 3 responses]
Don't try to use _afxBreakAlloc. Set a break-point on the MFC memory
allocator (search the MFC source for _afxBreakAlloc) -- the first time
it breaks should be when object 1 gets allocated. This isn't a good
technique if you're looking for a leak of the 500th allocated object,
but for object 1 or 2 it should work OK.
-----From: wallym@callan.win.net (Wally Meerschaert)
You can use CodeView to look at problems earlty in the
initialization process (from the beginning!) Added 2cents... If
possible (i.e., you have access to the hardware) use a second,
monochrome monitor and use cvw/2 to have the code on the mono
monitor and the program on the regular screen. This makes CV much
better to work with...
-----From: sanump@hcla.com (Sanu M.P)
Did you try with #defining DEBUG_NEW and getting the
source file and the exact line number of the allocation ?
If you haven't tried this out :
define DEBUG_NEW after all the statements that call the
IMPLEMENT_DYNCREATE or IMPLEMENT_SERIAL macros in your
module. Now the debug dump will show the line number of
the allcation which you probably didn't free.
Sanu. sanump@hcla.com
Larry Siden -- lsiden@jade.bioimage.com
Wednesday, May 08, 1996
[Mini-digest: 2 responses]
Jeff, thank you for your suggestion about setting a break-point on the
MFC memory allocator. I tried that. The module afxmem.cpp has a static
global int called lRequestLast that it post-increments each time it
assigns the allocation number to the appropriate field in the memory
header block. (That's the number that the dump function prints in
parens). The first time that AllocMemoryDebug() is called, this value
is already set to 7! I also tried setting a breakpoint on any change in
this value, before starting the program in stand-alone. Same thing! I
have no idea how the counter gets from 0 to 7 before my breakpoint can
hit. Examine afxmem.cpp and search for lRequestLast. You will see that
it can only be modified in this module (it is static) and it only
appears twice: once in its definition with an initializer (0!), and once
where it is used in a post-increment expression.
--
============================================================================
Larry Siden, Senior Software Engineer phone: 313-930-9900 x211 (w)
Bio Image, Inc.
777 E. Eisenhower Pky, Suite 950 email: (w) lsiden@bioimage.com
Ann Arbor, MI 48108 (h)
73677.1646@compuserve.com
-----From: Larry Siden
Wally, thank you for your suggestion about using CodeView.
Unfortunately, I don't have a second mono monitor. However, I can run
Windebug, the little applet that comes with VC++ for viewing the dump
stream. I have tried using CVW with this setup, but I still cannot
figure out where the rogue 28 bytes are being allocated because I cannot
get CV to break on the first allocation. The first time CV breaks, the
allocation counter lRequestLast defined as static in afxmem.cpp has
already been incremented to 7 (I am looking for the first and second
allocations)!
--
============================================================================
Larry Siden, Senior Software Engineer phone: 313-930-9900 x211 (w)
Bio Image, Inc.
777 E. Eisenhower Pky, Suite 950 email: (w) lsiden@bioimage.com
Ann Arbor, MI 48108 (h)
73677.1646@compuserve.com
Randal Parsons -- Randal.Parsons@btal.com.au
Monday, May 13, 1996
Larry Siden wrote:
>
> [Mini-digest: 2 responses]
>
> Jeff, thank you for your suggestion about setting a break-point on the
> MFC memory allocator. I tried that. The module afxmem.cpp has a static
> global int called lRequestLast that it post-increments each time it
> assigns the allocation number to the appropriate field in the memory
> header block. (That's the number that the dump function prints in
> parens). The first time that AllocMemoryDebug() is called, this value
> is already set to 7! I also tried setting a breakpoint on any change in
> this value, before starting the program in stand-alone. Same thing! I
> have no idea how the counter gets from 0 to 7 before my breakpoint can
> hit. Examine afxmem.cpp and search for lRequestLast. You will see that
> it can only be modified in this module (it is static) and it only
> appears twice: once in its definition with an initializer (0!), and once
> where it is used in a post-increment expression.
> --
I think you'll find that the first 7 allocations are global variables that are
created when the program starts up. In our case, I managed to trace the
allocations to find out what was causing the reported leak and then check by
hand the deallocation code to see if it was really a leak or not. Most of our
static allocations came from Objectspace's STL implementation. I don't think I
had to do anything too special to get it to break in the initial allocations,
but it was a while ago.
Regards,
Randal Parsons.
| Вернуться в корень Архива
|