James Sutherland wrote:
> >"many apps" do not check malloc() return values? I don't call them apps,
> >I call them first time students exercises. B-)
> >They're are not able to check malloc() return value but they can setup a
> >signal handler that triggers runtime a GC() clever enough not to page
> >fault itself? I don't follow you.
>
> If they don't bother handling errors of either sort, they just get
> terminated with a signal anyway. If they are careful enough to check
> malloc() every time, they would handle SIGBUS as well.
The problem here is the point at which you find you've run out of memory
is not a point where you can back out safely. How would you do so
anyway? Example without overcommit:
main()
{
syscall_just_this_process_overcommit(0);
char *p = (char *) malloc(1048576);
if(!p) {
printf("Hey we ran out of memory!\n");
return ENOMEM;
}
// this memory is guaranteed safe to acces
for(int i=0; i<1048576; i++) *p++ = i;
// some other stuff...
free(p);
return 0;
}
To handle SIGBUS's is completely impractical. You would have to change
the interrupted address to a bailout address. Example with overcommit:
void *bailout_addr = NULL;
void mysig() {
if(bailout_addr)
set_interrupted_address_somehow(bailout_addr);
}
main()
{
char *p = (char *) malloc(1048576);
if(!p) goto bailout;
bailout_addr = bailout;
signal(SIGBUS, mysig);
for(int i=0; i<1048576; i++) *p++ = i;
// etc...
free(p);
return 0;
bailout:
printf("Hey we ran out of memory!\n");
return ENOMEM;
}
Ignore the fact printf can run out of memory - in one of the apps I've
written I have a special version which can't.
Would you not agree that a SIGBUS is a completely silly way of finding
out you didn't get your memory? Now imagine this in a threaded app.
I'm actually making a patch against 2.2.14 to test this out. I'll see
what happens.
-- John Ripley, empeg Ltd. http://www.empeg.com- 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:36 EST