On Tue, 21 Mar 2000, James Sutherland wrote:
> Certainly, changing malloc() so it, in Java parlance, "raises an
> exception" (i.e. signals the process "something's gone pearshaped
> here") would help.
How? With overcommitting of memory, the only way to know if that memory
you just allocated is to:
1) Allocate the memory
2) check to see if the return from malloc() is null and throw an exception
if it is.
3) Set the SIGSEGV signal handler to a special handler
4) memset the memory to 0, touching every single page
5) If the memset segfaulted:
5a) long jump out of the signal handler
5b) reset the signal handler
5c) free the memory (we never really allocated it anyways)
5d) throw an exception
6) reset the signal handler
7) return the pointer to the allocated memory.
This is the problem with overcommitting memory: if you actually care
enough to try and write a program to do something sane on OOM, your life
has been made enormously more difficult.
> The number of apps which call malloc(), get zero,
> then try reading from or writing to their nice new buffer at address
> 0...
"Everyone else writes bad code- why should I write good code?"
>
> Handling one signal is a lot easier than checking every single return
> value from every single call, which is what you would need to handle
> OOM properly otherwise...
There is a difference between _allowing_ bad programming techniques, and
_requiring_ them. By overcommitting memory, you make checking the return
value of malloc useless. If you don't check the return value, and you're
out of memory, the behavior is the same either way- the program segfaults
(either by attempting to access overcommitted memory, or by dereferencing
a NULL pointer). If you do check those return values...
And most large projects _do_ override malloc with something similiar to:
void * xmalloc (size_t size) {
void * retval = malloc(size);
if (retval == NULL) longjmp(nomem_handler);
return retval;
}
Actually, that's an iffy statement today, and the trend is definately
towards better error handling. Consider all the code written in languages
like Perl, Python, and Java.
Brian
-
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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:35 EST