exit() and Memory leak reported

[Mike C#]

Hi all, quick question. I have an application I'm running. There are some
"fatal" error conditions that could occur during processing, and I want to
exit immediately if one comes up. When I put an exit() function call in my
code I get a message like this:

Detected memory leaks!
Dumping objects ->
{177} normal block at 0x003864E8, 32 bytes long.
Data: <c:\polling\inbou> 63 3A 5C 70 6F 6C 6C 69 6E 67 5C 69 6E 62 6F 75

With about 20 lines after the "Dumping objects->" line. If I put an exit()
function call immediately before the return statement in main(), it gives me
a message like the above but with only two lines after "Dumping objects->".

Finally, if I remove all exit() function calls and let it run all the way
through to the return in main(), no memory leak is reported and it
terminates normally. My question is should I be worried about this? And if
so, what can I do about it? The "memory leak" only seems to appear when I
terminate the code early, and does not appear as bad if I terminate later in
the application. Any ideas are welcome.

Thanks!

 

[Mike C#]

Oh yeah, I also noticed the "Data:" lines it's reporting in the object dump
match up exactly with the data for a bunch of static std::string public
variables in a class I created, if that makes a difference. Thanks.

 

[Bruno van Dooren]

Oh yeah, I also noticed the "Data:" lines it's reporting in the object
dump match up exactly with the data for a bunch of static std::string
public variables in a class I created, if that makes a difference.
Thanks.

I obviously don't have your code at hand, but this is expected behavior.
while you are debugging, the memory allocator keeps track of all
allocations.

each allocation that is not deallocated at the time of exit is considered
leaked.
by explicitly calling exit, you terminate your program without normal
deallocations.
As a result, anthying not de-allocated at that point is reported as a leak.

the destructor of your static strings is not executed until after the very
last return.
that explains why that is the only data reported as being leaked at that
point.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[Mike C#]

I obviously don't have your code at hand, but this is expected behavior.
while you are debugging, the memory allocator keeps track of all
allocations.

each allocation that is not deallocated at the time of exit is considered
leaked.
by explicitly calling exit, you terminate your program without normal
deallocations.
As a result, anthying not de-allocated at that point is reported as a
leak.

the destructor of your static strings is not executed until after the very
last return.
that explains why that is the only data reported as being leaked at that
point.

Thanks Bruno, that's what I suspected but wasn't sure. I've double-checked
everything and there don't appear to be any 'real' memory leaks. It just
threw me off to see that warning while debugging. Do you know of any way to
avoid that message? I.e., is there a way to force it to force that memory
leak check to wait until after the static strings are deallocated or is that
just something I have to live with?

Thanks

 

[Ben Voigt]

Thanks Bruno, that's what I suspected but wasn't sure. I've
double-checked everything and there don't appear to be any 'real' memory
leaks. It just threw me off to see that warning while debugging. Do you
know of any way to avoid that message? I.e., is there a way to force it
to force that memory leak check to wait until after the static strings are
deallocated or is that just something I have to live with?

Don't worry about any memory leaks that appear only when exit is called --
ExitProcess frees them.

Really, you aren't much concerned about static objects either, they consume
a fixed amount of space. It's the allocation-in-a-loop or periodic
allocation that isn't freed that causes problems. The memory toolkit
provides a feature (called snapshot or checkpoint) which you can call after
your startup code completes, and then again after performing some task, to
make sure that the task code cleaned up after itself properly.