VC++/VF memory leak or just poor programming ?

VC++/VF memory leak or just poor programming ?

Hello - I am wondering if someone could help me. I have written several programs that mix VC++ and VF. (Mostly VC++ calling VF.) All these codes seem to exhibit a small memory leak no matter how I include the FORTRAN (directly as part of the project or via a FORTRAN dll).
(I have moved the FORTRAN libraries so the are the last to be linked against per another posting on this forum.)
If I remove references to FORTRAN code - the leak goes away. Example: At the end of execution of one of these codes I get something like (inside Visual Studio)...

Detected memory leaks!
Dumping objects ->
{44} normal block at 0x01902700, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{43} normal block at 0x01902698, 40 bytes long.
Data: < |L > 14 7C 4C 10 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.

Notice the relatively low allocation count number (i.e. {43}).

I get this in both MFC based or console based code.

In a MFC based code I put some thing like...

CMemoryState diffMemState;

CmyApp::CmyApp()
{
diffMemState.DumpAllObjectsSince();
}

I do this to dump all the allocated objects before any significant processing of my code has begun. What I will see is that the memory blocks that are reported as part of a memory leak were allocated BEFORE the construction of myApp (in a MFC app).

Something like this will be reported...

Dumping objects ->
{56} client block at 0x01904538, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $01904538, 64 bytes long
{51} client block at 0x019029B0, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $019029B0, 64 bytes long
{49} client block at 0x01902860, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $01902860, 64 bytes long
{44} normal block at 0x01902700, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{43} normal block at 0x01902698, 40 bytes long.
Data: < |L > 14 7C 4C 10 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.

Notice, data blocks 43 and 44 have already been allocated before my code has even got a chance to get rolling. They were allocated somewhere in the initialization.

I have stripped several of these codes down to bare-bones and I still get this type of memory leak. This happens even if I make just one call to a small, do-nothing, FORTRAN routine that takes no parameters.

I have also begun execution of the code via the debugger and set the _crtBreakAlloc system variable to the lowest numbered allocation block so that the debugger will stop when the block is allocated. Execution stops down inside the bowels of the MS Windows initialization code. I have even tried adding a memory allocation hook routine via _CrtSetAllocHook() but I can't register it with the system until my portion of the code begins to execute and by then it is to late, the blocks of concern have already been allocated.

If anyone has any ideas about what I am doing wrong please let me know.

Thanks
Dan

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Ignore this. The VC++ Debug RTL makes an assumption that all memory allocation and deallocation is done in VC++ code. When you bring Fortran into it, the Fortran RTL is doing its own allocations, some of which it hangs onto until image exit. The VC++ RTL doesn't understand this and complains about memory leaks. The Fortran RTL is invoked automatically at initialization.

Steve

Steve - Intel Developer Support

Steve,

Thanks alot, I'm breathing alot easier now. If this is not the result of some silly mistake I have made, is there a way to not recieve this message? (I am afraid that if I start ignoring erroneous warnings I will run the chance of missing a legitimate one.) I don't remember reading of anyone else having this problem. Any ideas?

Thanks Again
Dan

You'll only get this when building against the debug MFC libraries. I don't know of a way to shut off the messages specifically.

Steve

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today