Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Do I need to free all memory that is malloced?

Reply
Thread Tools

Do I need to free all memory that is malloced?

 
 
Mark McIntyre
Guest
Posts: n/a
 
      09-26-2005
On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,
http://www.velocityreviews.com/forums/(E-Mail Removed) (Richard Bos) wrote:

>Very nearly nothing a mere user program does will bring a modern,
>well-written OS down.


That the funniest thing I've heard this year!

Dont try this at home
$ sudo root
$ rm -rf /

(root is a user too, you know...)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      09-26-2005
Mark McIntyre <(E-Mail Removed)> writes:
> On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,
> (E-Mail Removed) (Richard Bos) wrote:
>
>>Very nearly nothing a mere user program does will bring a modern,
>>well-written OS down.

>
> That the funniest thing I've heard this year!
>
> Dont try this at home
> $ sudo root
> $ rm -rf /
>
> (root is a user too, you know...)


$ sudo root
sudo: root: command not found

But yes, I see what you mean.

All you've done here is illustrate the difference between "very nearly
nothing" and "nothing".

It would be more accurate to say that very nearly nothing a user
program running without elevated privileges does will bring down a
modern OS. There are, of course, exceptions (OS bugs,
denial-of-service attacks, etc.).

The narrower point here is that calling free() with an invalid pointer
(e.g., "p = malloc(whatever); free(p+2);") is likely to crash the
individual program, but is highly unlikely to crash the entire OS.

But that's far beyond anything the C standard guarantees, or even
discusses. There may or may not even be an OS. Either way, an
invalid free() invokes undefined behavior; if it *does* crash the OS,
it's the OS's fault, not C's fault.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
 
 
 
Richard Bos
Guest
Posts: n/a
 
      09-27-2005
Mark McIntyre <(E-Mail Removed)> wrote:

> On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,
> (E-Mail Removed) (Richard Bos) wrote:
>
> >Very nearly nothing a mere user program does will bring a modern,
> >well-written OS down.

>
> That the funniest thing I've heard this year!
>
> Dont try this at home
> $ sudo root
> $ rm -rf /
>
> (root is a user too, you know...)


"Very nearly nothing" and "a mere user program" do kinda imply "not
actively suicidal", really.

Richard
 
Reply With Quote
 
Ian Malone
Guest
Posts: n/a
 
      09-27-2005
Emmanuel Delahaye wrote:
> Charles Sullivan wrote on 26/09/05 :
>
>> On Sun, 25 Sep 2005 22:51:09 +0200, Emmanuel Delahaye wrote:
>> <snip>
>>
>>> However, the allocated bloc can be shriked with realloc(). Be sure
>>> you have alot of byte to spare because realloc() isn't cheap...

>>
>>
>> Can you expound on this a little? Is the memory used by realloc()
>> at any one time substantially greater than the old allocation
>> plus the new allocation? And isn't the old allocation freed?

>
>
> If you are to spare just a few bytes, don't call realloc(). It costs in
> terms of
> - development (the good use of realloc() is not trivial, see the FAQ)


The only reference I can see in the clc faq is to passing null
to realloc. The only gotcha I'm aware off with respect to realloc
is the need to check the return value before changing the pointer,
so it requires a temporary variable. That seems fairly trivial.

> - time execution (realloc() can be a slow function)
>


This is certainly true on implementations I've used,
I would guess shrinking is faster than expanding
(probably no need to move and therefore no need to
copy the allocated memory). 100% implementation
dependant of course.

> Not to mention that in most cases, the gain is close to 0 because the
> 'internal memory blocks' have a minimum size (say 32 or 64 bytes). It's
> all a matter of implementation.
>


Indeed, I'm not sure realloc is even guaranteed to free
the released memory for further use[1]. Whether it's
worth doing probably depends on your overestimation
of the array size.

[1] Except in this case: "If the realloc function returns a
null pointer when size is zero and ptr is not a null
pointer, the object it pointed to has been freed."

--
imalone
 
Reply With Quote
 
Anonymous 7843
Guest
Posts: n/a
 
      09-27-2005
In article <(E-Mail Removed)4all.nl>,
Richard Bos <(E-Mail Removed)> wrote:
> "Alexei A. Frounze" <(E-Mail Removed)> wrote:
> >
> > free (ip+2) is wrong. It shouldn't normally bring the system down,

>
> Very nearly nothing a mere user program does will bring a modern,
> well-written OS down.


int main(void)
{
while(1)
{
malloc(1000000);
fork();
}
}

/* Sure, it's not conforming, but neither is free(ip+2). */
 
Reply With Quote
 
Alexei A. Frounze
Guest
Posts: n/a
 
      09-27-2005
"Anonymous 7843" <(E-Mail Removed)> wrote in message
news:gAf_e.16345$mH.15336@fed1read07...
> int main(void)
> {
> while(1)
> {
> malloc(1000000);
> fork();
> }
> }
> /* Sure, it's not conforming, but neither is free(ip+2). */


Even w/o fork() it can be very bad (depends on the system) and yet be
conforming...

Alex


 
Reply With Quote
 
embedhere
Guest
Posts: n/a
 
      09-28-2005

Ian Malone wrote:
> Emmanuel Delahaye wrote:
> > Charles Sullivan wrote on 26/09/05 :
> >
> >> On Sun, 25 Sep 2005 22:51:09 +0200, Emmanuel Delahaye wrote:
> >> <snip>
> >>
> >>> However, the allocated bloc can be shriked with realloc(). Be sure
> >>> you have alot of byte to spare because realloc() isn't cheap...
> >>
> >>
> >> Can you expound on this a little? Is the memory used by realloc()
> >> at any one time substantially greater than the old allocation
> >> plus the new allocation? And isn't the old allocation freed?

> >
> >
> > If you are to spare just a few bytes, don't call realloc(). It costs in
> > terms of
> > - development (the good use of realloc() is not trivial, see the FAQ)

>
> The only reference I can see in the clc faq is to passing null
> to realloc. The only gotcha I'm aware off with respect to realloc
> is the need to check the return value before changing the pointer,
> so it requires a temporary variable. That seems fairly trivial.
>
> > - time execution (realloc() can be a slow function)
> >

>
> This is certainly true on implementations I've used,
> I would guess shrinking is faster than expanding
> (probably no need to move and therefore no need to
> copy the allocated memory). 100% implementation
> dependant of course.
>
> > Not to mention that in most cases, the gain is close to 0 because the
> > 'internal memory blocks' have a minimum size (say 32 or 64 bytes). It's
> > all a matter of implementation.
> >

>
> Indeed, I'm not sure realloc is even guaranteed to free
> the released memory for further use[1]. Whether it's
> worth doing probably depends on your overestimation
> of the array size.
>
> [1] Except in this case: "If the realloc function returns a
> null pointer when size is zero and ptr is not a null
> pointer, the object it pointed to has been freed."
>
> --
> imalone



Hello Friends,
Can somebody come up with a code snippet for the same?
Thanks,
Balakrishna

 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      09-28-2005

In article <gAf_e.16345$mH.15336@fed1read07>, (E-Mail Removed) (Anonymous 7843) writes:
> In article <(E-Mail Removed)4all.nl>,
> Richard Bos <(E-Mail Removed)> wrote:
> >
> > Very nearly nothing a mere user program does will bring a modern,
> > well-written OS down.

>
> int main(void)
> {
> while(1)
> {
> malloc(1000000);
> fork();
> }
> }
>
> /* Sure, it's not conforming, but neither is free(ip+2). */


That won't cause a problem for a modern, well-written, correctly
configured OS. Properly configured POSIX systems have reasonable
resource limits set.

For that matter, most of the modern POSIX systems I use deal
relatively well with resource exhaustion - they certainly don't go
down. They may have to kill off some noncritical processes, but
the OS itself stays running.

--
Michael Wojcik (E-Mail Removed)

Maybe, but it can't compete with _SNA Formats_ for intricate plot
twists. "This format is used only when byte 5, bit 1 is set to 1
(i.e., when generalized PIU trace data is included)" - brilliant!
 
Reply With Quote
 
Anonymous 7843
Guest
Posts: n/a
 
      09-28-2005
In article <(E-Mail Removed)>,
Michael Wojcik <(E-Mail Removed)> wrote:
>
> In article <gAf_e.16345$mH.15336@fed1read07>, (E-Mail Removed)
> (Anonymous 7843) writes:
> > In article <(E-Mail Removed)4all.nl>,
> > Richard Bos <(E-Mail Removed)> wrote:
> > >
> > > Very nearly nothing a mere user program does will bring a modern,
> > > well-written OS down.

> >
> > int main(void)
> > {
> > while(1)
> > {
> > malloc(1000000);
> > fork();
> > }
> > }
> >
> > /* Sure, it's not conforming, but neither is free(ip+2). */

>
> That won't cause a problem for a modern, well-written, correctly
> configured OS. Properly configured POSIX systems have reasonable
> resource limits set.
>
> For that matter, most of the modern POSIX systems I use deal
> relatively well with resource exhaustion - they certainly don't go
> down. They may have to kill off some noncritical processes, but
> the OS itself stays running.


I've tried out the above snippet on dozens of unix/posix/linux
machines. You're right, they don't always crash, but more often
than not the machine is essentially unusable and needs to be
rebooted. Perhaps it is just my bad luck to encounter only
incorrectly configured systems; or the number of correctly
configured systems is lower than ideal.
 
Reply With Quote
 
Randy Howard
Guest
Posts: n/a
 
      09-29-2005
Mark McIntyre wrote
(in article <(E-Mail Removed)>):

> On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,
> (E-Mail Removed) (Richard Bos) wrote:
>
>> Very nearly nothing a mere user program does will bring a modern,
>> well-written OS down.

>
> That the funniest thing I've heard this year!
>
> Dont try this at home
> $ sudo root
> $ rm -rf /
>
> (root is a user too, you know...)


$ sudo cat < /dev/zero > /dev/mem

is pretty exciting, and much faster.



--
Randy Howard (2reply remove FOOBAR)

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
How memory function free() knows how much memory to free. Panduranga Chary C Programming 2 12-27-2007 06:01 AM



Advertisments