Re: You don't check for malloc failure

On 05/08/2011 01:06 AM, Romain Beauxis wrote:
> Running out of memory is not considered as an error when calling malloc?

On linux, the only way to get an error when calling malloc() is to 
disable memory-overcommiting. On regular linux systems, this is the 
_only_ way for malloc() to return NULL. If an icecast process reaches 
that point, it's screwed anyway it won't be able to do anything 
meaningful: any source reads will fail (refbuf alloc), any log print 
will also fail (printf uses malloc too), so it might as well give up and 
call abort().

However, even doing that is useless for 2 reasons:

  - adding abort()s everywhere bloats the code and add code paths that 
are unlikely to be tested. Complex test suites are mandatory for this to 
succeed, otherwise icecast may not work as intended when encountering a 
malloc() error.

  - as has been said by Maarten, memory errors are much more likely (I'm 
talking orders of magnitude) to manifest themselves as SIGKILL rather 
than malloc() returning NULL.

Bottom line, checking what malloc() returns is just useless on modern 
desktop/server operating systems, don't do it.

Instead, icecast should keep its memory footprint low and avoid leaks at 
all costs. Even with massive numbers of sources/clients, these 2 goals 
alone should keep icecast under the OOM Killer's radar.

Here are a couple references:

http://blog.ometer.com/2008/02/04/out-of-memory-handling-d-bus-experience/

http://article.gmane.org/gmane.comp.audio.jackit/19998

Cheers,

Rémi