[Icecast-dev] You don't check for malloc failure
toots at rastageeks.org
Mon May 9 07:40:17 PDT 2011
2011/5/9 Rémi Cardona <remi.cardona at smartjog.com>:
> 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
> 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:
> Icecast-dev mailing list
> Icecast-dev at xiph.org
More information about the Icecast-dev