Re: You don't check for malloc failure

2011/5/9 Rémi Cardona <[email protected]>:
> 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.

Ok, thanks guys for the explanations!

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

I am not so sure about that tho. We're talking about a specified
behaviour.. What about on other POSIX systems? OSX? Minix? FreeBSD?
It's not because Linux never returns NULL that its makes it useless to
check 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
> _______________________________________________
> Icecast-dev mailing list
> [email protected]
> http://lists.xiph.org/mailman/listinfo/icecast-dev
>