[Icecast-dev] You don't check for malloc failure
remi.cardona at smartjog.com
Mon May 9 00:46:43 PDT 2011
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
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
- 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:
More information about the Icecast-dev