program termination/memory leaks

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?

re: program termination/memory leaks

J. Campbell wrote:[color=blue]
> 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?[/color]

The operating system reclaims all resources used by the process when the
process exits.
[color=blue]
>
> And the same question when an array is placed on the heap by a class
> constructor, with delete being called in the destructor.[/color]

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


What happens[color=blue]
> when the program stops before the object goes out of scope?[/color]

"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

re: program termination/memory leaks

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




"J. Campbell" <mango_maniac@yahoo.com> wrote in message
news:b97c86e1.0309110811.4f8f8ba5@posting.google.c om...[color=blue]
> 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?[/color]

re: program termination/memory leaks

Gianni Mariani wrote:
[color=blue]
> The operating system reclaims all resources used by the process when the
> process exits.
>[/color]

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: program termination/memory leaks

Kevin Goodsell wrote:[color=blue]
> Gianni Mariani wrote:
>[color=green]
>> The operating system reclaims all resources used by the process when
>> the process exits.
>>[/color]
>
> 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).[/color]

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

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

re: program termination/memory leaks

Gianni Mariani wrote:[color=blue]
> Kevin Goodsell wrote:
>[color=green]
>> Gianni Mariani wrote:
>>[color=darkred]
>>> The operating system reclaims all resources used by the process when
>>> the process exits.
>>>[/color]
>>
>> 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).[/color]
>
>
> That'l teach you for using Windows ! :^)
>
> Right you are - it may be that you are writing the "operating system" !
>[/color]

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: program termination/memory leaks

J. Campbell wrote:
[color=blue]
> What happens to allocated memory
> when a program terminates before the memory is released?[/color]

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

re: program termination/memory leaks

[color=blue]
> 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.)
>[/color]

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

re: program termination/memory leaks

On Thu, 11 Sep 2003 13:32:41 -0700, "E. Robert Tisdale"
<E.Robert.Tisdale@jpl.nasa.gov> wrote in comp.lang.c++:
[color=blue]
> J. Campbell wrote:
>[color=green]
> > What happens to allocated memory
> > when a program terminates before the memory is released?[/color]
>
> The operating system reclaims all memory allocated for the process
> whether the program terminates normally or not.[/color]

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

re: program termination/memory leaks

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.

re: program termination/memory leaks

Jack Klein wrote:
[color=blue]
> 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.[/color]

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.

re: program termination/memory leaks

J. Campbell wrote:
[color=blue]
> If the OS reclaims resources upon process termination,
> why does my PC need a periodic reboot?[/color]

This is common knowledge.
Because you are running Microsoft Windows.
Windows users have learned to expect that
they must reboot periodically.
[color=blue]
> uptime[/color]
9:34pm up 22 days, 13:17, 3 users, load average: 0.24, 0.12, 0.06[color=blue]
> uname[/color]
Linux

re: program termination/memory leaks

[color=blue][color=green]
> > If the OS reclaims resources upon process termination,
> > why does my PC need a periodic reboot?[/color]
>
> This is common knowledge.
> Because you are running Microsoft Windows.
> Windows users have learned to expect that
> they must reboot periodically.
>[color=green]
> > uptime[/color]
> 9:34pm up 22 days, 13:17, 3 users, load average: 0.24, 0.12, 0.06[color=green]
> > uname[/color]
> Linux[/color]

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...

re: program termination/memory leaks

"J. Campbell" wrote:
[color=blue]
> Hmm...do I believe the majority?[/color]


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

re: program termination/memory leaks

llewelly <llewelly.at@xmission.dot.com> wrote in message news:<lzisnx65g8.fsf@Britschs-Computer.local.bar>...[color=blue]
> mango_maniac@yahoo.com (J. Campbell) writes:
>[color=green]
> > 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?[/color]
>
> 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.
>[/color]

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

[color=blue][color=green]
> > 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.[/color]
>
> 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.
>[/color]
Thanks for the tip
[color=blue]
>
> 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.[/color]

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.