* Farooq Mela <[EMAIL PROTECTED]> [010223 00:22] wrote:
> Alfred Perlstein wrote:
> >
> > * Farooq Mela <[EMAIL PROTECTED]> [010222 23:52] wrote:
> > >
> > > This is not what I am arguing. I gave a simple example of an xmalloc
> > > function which does just print an error and exit. However, I've written
> > > many large applications using this sort of scheme where when allocation
> > > fails, all sorts of cleanup is performed before the process exits
> > > (cleaning up & restoring terminal mode, gracefully closing files /
> > > sockets / etc, syslogging the event, etc). It is hardly ever a simple
> > > exit as soon as allocation fails.
> >
> > Here's exactly what's wrong with your idea:
> >
> > Some internal libc function that _can_ gracefully handle an out
> > of memory return will not be able to do so if your malloc wrappers
> > wrest control out from under them.
> >
> > Honestly, any code is somewhat flawed if it doesn't take extra care
> > not to have sections where an abrupt shutdown can cause a lot of
> > damage or inability to recover on restart. However...
> >
> > Some internal libc functions may attempt an allocation while in the
> > midst of doing something evil to your program such as fiddling with
> > signal masks or timers, if you get your "out of memory" callback
> > and the libc function hasn't had time to restore your normal program
> > context, you're going to have a world of pain to deal with.
> >
> > I can't provide any specific examples of this potentially happening,
> > but I can imagine it being a problem, especially deep within something
> > like the userland thread library or other complex library.
> >
> > If you need to deal with asprintf problems, then make an xasprinf
> > that does the callback in your context, not from deep within libc.
>
> I agree. Some instances of malloc failure can be / must be dealt with
> gracefully in libc. I am not saying that ALL usages of malloc would be
> replaced with calling the user-settable allocator. Only those that are
> not modifying, as you mentioned, the process' signal disposition and
> other such attributes, and *certainly* not from within the thread
> library.
>
> Anyway, doesnt seem like this idea is about to fly. I guess I'll shut up
> now. :-)
Well, while looking at actually doing what you're saying, phk malloc
will call a function (from the manpage):
void
(*_malloc_message)(char *p1, char *p2, char *p3, char *p4)
you can set _malloc_message = your callback.
the only problem is that the failure codes don't seem to be
enumerated, they seem to be strings, if there was a way to test:
/*
* this is untested
*/
void (*saved_malloc_callback)(char *p1, char *p2, char *p3, char *p4);
void
my_malloc_callback(char *p1, char *p2, char *p3, char *p4)
{
if (p1 == malloc_out_of_memory_str) {
/* do out of memory handling */
} else {
saved_malloc_callback(p1, p2, p3, p4);
}
}
int
main (void) {
saved_malloc_callback = _malloc_message;
_malloc_message = my_malloc_callback;
more_main();
}
or something, you could then hijack _malloc_message for your
callback.
Of course this would be highly FreeBSD specific, but so would the
modification you wanted in the first place.
Poul-Henning, is there any way to do a valid test to determine that
the '_malloc_message' callback parameter means "out of memory"?
I'm pretty sure that we should discourage anyone wanting to abuse
the interface by doing this, but it does seem sort of interesting.
:)
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
