Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Feb 2001 00:16:02 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Farooq Mela <fmela0@sm.socccd.cc.ca.us>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Setting memory allocators for library functions.
Message-ID:  <20010223001602.E8663@fw.wintelcom.net>
In-Reply-To: <3A96176A.CFE695F@sm.socccd.cc.ca.us>; from fmela0@sm.socccd.cc.ca.us on Thu, Feb 22, 2001 at 11:55:22PM -0800
References:  <200102230728.f1N7SW619041@guild.plethora.net> <3A96176A.CFE695F@sm.socccd.cc.ca.us>

next in thread | previous in thread | raw e-mail | index | archive | help
* 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.

-Alfred

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010223001602.E8663>