Messages in this thread | | | Date | Tue, 21 Mar 2000 17:59:28 -0600 (CST) | From | Brian Hurt <> | Subject | Re: Some questions about linux kernel. |
| |
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/
| |