lkml.org 
[lkml]   [1998]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: A true story of a crash.
Date
From
Michael Driscoll wrote:
> >Well, this overcommitment is fine in some cases, and not in others. A
> >kernel option that enables the no overcommit case would be nice for
> >some people.
> >
> >The argument FOR overcommitting memory is:
> >
> > Almost nobody check the malloc return values. And if they do, all
> > they do is bomb out with "out of memory". If you keep such a
> > process, it might even run to completion.
>
> There are people out there who don't check the return of malloc()? Yuck.
> I've *always* made it a habit to define my own xmalloc() which bombs with
> an error messages on malloc() return of NULL. If there are people who
> don't check the return of malloc(), then they get what's coming to then
> (unpredictable crashes in heavy load, for one).

You see, that's what I meant. Instead of bombing out with a segmentation
fault core dumped, your program bombs out with a "malloc failed".

It is slightly more informative, but doesn't buy the user
anything. Application quit. Period.

Roger.

--
| The secret of success is sincerity. Once you can | R.E.Wolff@BitWizard.nl
| fake that, you've got it made. -- Jean Giraudoux | T: +31-15-2137555
- Custom Linux device drivers for sale! Call for a quote. - F: +31-15-2138217

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.342 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site