__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