__uc_malloc hooks
Denys Vlasenko
vda.linux at googlemail.com
Mon Sep 17 10:00:23 UTC 2007
On Monday 17 September 2007 05:03, Rob Landley wrote:
> On Saturday 15 September 2007 3:19:33 am Mike Frysinger wrote:
> > more to the point ... how exactly would __uc_malloc be useful ? i dont
> > think ive ever seen malloc() return NULL as the kernel is the first to find
> > out about the OOM situation and properly nukes any userspace app before it
> > ever sees the relevant NULL ...
> > -mike
>
> Generally malloc() returns NULL when you've exhausted virtual memory (not
> physical memory, which you find out about after the fact by the OOM killer
> shooting you in the head when you dirty enough pages).
Or when you hit a rlimit. Don't forget about it, it's a valid scenario
where users of libc have every right to expect correct behavior.
> Not much of a concern
> on 64 bit platforms, but on 32 bit you can trivially run into this if you've
> done a couple of large mmap() calls...
>
> That said, testing for NULL is seldom useful because attempts to use the
> result give you a nice null pointer dereference and a segfault, cleanly
> ending the program anyway.
For libc, this is not acceptable. libc has (potentially) diverse set of users,
some of them absolutely must have robust out-of-memory reporting (e.g. databases).
Because of that it's inacceptable to do this in libc:
char *tempbuf = malloc(sz);
if (!tempbuf)
abort();
__uc_malloc() solves this problem. For 99% of users which don't care,
it works exactly as above piece pf code. For the remaining 1%
who care and installed a callback, it returns a notification.
--
vda
More information about the uClibc
mailing list