Date: Fri, 23 Feb 2001 00:33:15 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Farooq Mela <fmela0@sm.socccd.cc.ca.us> Cc: freebsd-hackers@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <20010223003315.G8663@fw.wintelcom.net> In-Reply-To: <3A961EA4.D8EA89B5@sm.socccd.cc.ca.us>; from fmela0@sm.socccd.cc.ca.us on Fri, Feb 23, 2001 at 12:26:12AM -0800 References: <200102230728.f1N7SW619041@guild.plethora.net> <3A96176A.CFE695F@sm.socccd.cc.ca.us> <20010223001602.E8663@fw.wintelcom.net> <3A961EA4.D8EA89B5@sm.socccd.cc.ca.us>
index | next in thread | previous in thread | raw e-mail
* Farooq Mela <fmela0@sm.socccd.cc.ca.us> [010223 00:22] wrote:
> Alfred Perlstein wrote:
> >
> > * Farooq Mela <fmela0@sm.socccd.cc.ca.us> [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 - [bright@wintelcom.net|alfred@freebsd.org]
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010223003315.G8663>