From owner-freebsd-hackers Fri Feb 23 0:33:19 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E14CB37B491; Fri, 23 Feb 2001 00:33:15 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1N8XFB13423; Fri, 23 Feb 2001 00:33:15 -0800 (PST) Date: Fri, 23 Feb 2001 00:33:15 -0800 From: Alfred Perlstein To: Farooq Mela Cc: freebsd-hackers@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. Message-ID: <20010223003315.G8663@fw.wintelcom.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Farooq Mela [010223 00:22] wrote: > Alfred Perlstein wrote: > > > > * Farooq Mela [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