program termination/memory leaks

[J. Campbell]

what happens to allocated memory when a program terminates before the
memory is released. For example:

int main(){
int* array;
int a_size = 1000;
array = new int[a_size];
for(int i = 0; i < a_size; ++i){
if(i > (a_size/2))
return 0; //oops...ended before delete...is this a problem?
}
delete[] array;
return 0;
}

If this is a leak, does the same thing happen when you "ctrl-break" a
running program?

And the same question when an array is placed on the heap by a class
constructor, with delete being called in the destructor. What happens
when the program stops before the object goes out of scope?

 

[Gianni Mariani]

what happens to allocated memory when a program terminates before the
memory is released. For example:

int main(){
int* array;
int a_size = 1000;
array = new int[a_size];
for(int i = 0; i < a_size; ++i){
if(i > (a_size/2))
return 0; //oops...ended before delete...is this a problem?
}
delete[] array;
return 0;
}

If this is a leak, does the same thing happen when you "ctrl-break" a
running program?

The operating system reclaims all resources used by the process when the
process exits.

And the same question when an array is placed on the heap by a class
constructor, with delete being called in the destructor.

You must explicity delete all object you create with new. Only
automatic, static or global variables are deleted automatically by the
compiler.


What happens

when the program stops before the object goes out of scope?

"program stops" ?

There are various ways a program may stop. Which ones are you referring
to ?

a) Power failure

b) low level exit

c) stopped in the debugger

e) terminated asynchronously

g) suspended

.... probably more

 

[dwrayment]

to answer your question. YES that is a memory leak. dont do that.

 

[Kevin Goodsell]

The operating system reclaims all resources used by the process when the
process exits.

Oh? As far as I know, this is not required by the standard. I've seen a
system that lost memory that was not explicitly freed. It was pretty
much gone forever, even if the system was turned off and back on. The
only way to reclaim it was to wipe the entire memory (the equivalent of
formating your hard disk).

-Kevin

 

[Gianni Mariani]

Oh? As far as I know, this is not required by the standard. I've seen a
system that lost memory that was not explicitly freed. It was pretty
much gone forever, even if the system was turned off and back on. The
only way to reclaim it was to wipe the entire memory (the equivalent of
formating your hard disk).

That'l teach you for using Windows ! :^)

Right you are - it may be that you are writing the "operating system" !

 

[E. Robert Tisdale]

What happens to allocated memory
when a program terminates before the memory is released?

The operating system reclaims all memory allocated for the process
whether the program terminates normally or not.

 

[Kevin Goodsell]

That'l teach you for using Windows ! :^)

Right you are - it may be that you are writing the "operating system" !

The system in question was actually a calculator. It had its own OS, but
it wasn't really designed for third-party programming. Since its state
is maintained when the power is off (either by the main batteries or a
separate backup battery), it couldn't really be 'rebooted' without
deleting everything in memory - which is where everything short of the
OS itself is stored. (Well, that's not entirely true - there was some
non-volatile RAM that wasn't used by the OS that could be used for
archiving 'files' and such.)

-Kevin

 

[Patrick Hoonhout]

The system in question was actually a calculator. It had its own OS, but
it wasn't really designed for third-party programming. Since its state
is maintained when the power is off (either by the main batteries or a
separate backup battery), it couldn't really be 'rebooted' without
deleting everything in memory - which is where everything short of the
OS itself is stored. (Well, that's not entirely true - there was some
non-volatile RAM that wasn't used by the OS that could be used for
archiving 'files' and such.)

This is the std C++ group. OS calculator programming questions should go to
the appropriate calculator news group... :*)

 

[Jack Klein]

The operating system reclaims all memory allocated for the process
whether the program terminates normally or not.

Can you cite the reference to the clause of the C++ standard that
states that requirement?

Alternatively, can you provide proof that you have tested this on
every single operating system in existence and found it to be true?
And proof that an operating system due to be released next year it
will also be true?

Neither C++ no any other language standard can impose requirements on
the operating system that executes programs.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[J. Campbell]

Thanks for the advice, guys.

Gianni Mariani wrote:
"The operating system reclaims all resources used by the process when
the
process exits."

dwrayment wrote:
"YES that is a memory leak."

E Robert Tisdale wrote:
"The operating system reclaims all memory allocated for the process
whether the program terminates normally or not."


Hmm...do I believe the majority? My real concern was that I was doing
some tests where I had created arrays containing 10's of MBs, but
"ctrl-break"ed the program, as I was just testing and didn't want to
wait for it to finish running. I just wanted to make sure that I
wasn't losing resources by doing this. Sounds like it's no prob.

So...this is a related OT Q. Sorry Kevin G ;-) for the OT post, as
you seem to be (gracefully, and helpfully) wearing the comp.lang.c++
Protocol Police badge & baton at the moment. Anyway...if the OS
reclaims resources upon process termination, why does my PC need a
periodic reboot??

Thanks again.

 

[E. Robert Tisdale]

Can you cite the reference to the clause of the C++ standard that
states that requirement?

Alternatively, can you provide proof that you have tested this on
every single operating system in existence and found it to be true?
And proof that an operating system due to be released next year it
will also be true?

Neither C++ no any other language standard can impose requirements on
the operating system that executes programs.

I'm sorry that I didn't mention that
this subject was off-topic in the comp.lang.c++ newsgroup.
Now we're both off-topic.

 

[E. Robert Tisdale]

If the OS reclaims resources upon process termination,
why does my PC need a periodic reboot?

This is common knowledge.
Because you are running Microsoft Windows.
Windows users have learned to expect that
they must reboot periodically.

uptime

9:34pm up 22 days, 13:17, 3 users, load average: 0.24, 0.12, 0.06

uname

Linux

 

[Duane Hebert]

This is common knowledge.
Because you are running Microsoft Windows.
Windows users have learned to expect that
they must reboot periodically.

9:34pm up 22 days, 13:17, 3 users, load average: 0.24, 0.12, 0.06
Linux

Not sure about Linux but Windows doesn't do garbage collection. Generally,
without garbage collection
how can memory be released if the dtor isn't called? You should never
depend on the OS releasing memory. You allocate it, you should release it.

BTW I've been running Win2k pro for 2 years at home without a reboot. Can't
say the same for Redhat...

 

[Default User]

Hmm...do I believe the majority?

If it comes down to the majority vs. Tisdale, go with the majority. In
fact, if Tisdale is in opposition to ANY other opinion, your safest bet
is to go with the other. Tisdale is wrong, and stubbornly bull-headly
wrong, an inordinate amount of the time. He also likes to troll.




Brian Rodenborn

 

[J. Campbell]

These views are not contradictatory. You do have a memory leak, but
most evironments will clean up remaining memory leaks (in some
sense) when a process exits, but I have used a few which did
not. Your environment's behavior may make this memory leak
unimportant. Sometimes you will find yourself extending a program
in a way that makes a previously non-important memory leak
important. Sometimes you will find it is significantly cheaper to
let the environment clean up after you. The safe bet is to
prevent all resource leaks yourself, and not rely on the
environment to clean them up - unless performance (or development)
needs dictate otherwise.

Please note the C++ standard says nothing about any of this; either
kind of environment can host a fully conforming C++
implementation.

Thanks for the very complete explaination...it helps a lot.

I think I have used DOS and windows95 IDEs where this was a problem iff
the program was launched from the IDE. I do not think it is a
common problem.

Thanks for the tip

In any case, memory is not the only resource, and new / malloc are
not the only ways to acquire memory (though the other ways are
outside C++). Maybe your OS gives fewer cleanup guarantees for
other resources.

For the boxen I have around the house, ' periodic reboot ' is about
once every 3-6 months, and typically caused by a need to move the
machine beyond its cordage, or install new hardware. So I'm not
sure why you need to reboot.

I was actually kinda joking about the reboot biz, as the thread had
already gotten a little OT. My win xp machine almost never crashes,
although I do turn it off most nights. However, applications, eg my
compiler crashes pretty regularly...no fault of the OS. I do like NT
(oops...i mean xp) compared to 3.11, 95, 98 that I used before. NT 4
was good too...I haven't really had stability problems since win 95
(before the service release)...

Anyway...thanks again. My take-home message is that if ctrl-breaking
out of progs I'm writing, perhaps it's better to access the console
from *outside* the IDE interface, as doing so from within may
(shall??) cause a memory leak...and subsequent crash (bloodshed indeed
*did* crash on me twice today while working with progs that had circa
11 MB in memory...and I was breaking out of them from the IDE!!) That
was why I posted in the first place.

Thanks guys...I think I understand this issue...now for multiple
inheritance...maybe next week.