memory leaking

Erik Hovland erik at hovland.org
Sat Jun 17 00:23:52 UTC 2006


The config item 'FEATURE_CLEAN_UP' says :
---------------------
As a size optimization, busybox normally exits without explicitly
freeing dynamically allocated memory or closing files.  This saves
space since the OS will clean up for us, but it can confuse debuggers
like valgrind, which report tons of memory and resource leaks.

Don't enable this unless you have a really good reason to clean
things up manually.
----------------------

That is fine and I generally agree. But there is another trade off
associated to this and that is not freeing memory could cause failure of
applications in corner cases because it runs out of memory. I don't have
specific examples or test cases of this. So I am trying to begin some
sort of discussion.

There are at least two cases where I can think this is important. One
example is a daemon, which might be long lived. In this situation if an
exit is not in the near future a function should free any memory it
allocates and is finished using. The other is where something reports
over input like less or patch. These apps might have very large inputs
and they may sometimes process chunk by chunk but they will OOM if they
don't give up chunks they don't use any more.

Should all resource leak fixing be wrapped in
some variation of FEATURE_CLEAN_UP? Or is there a rule of thumb
regarding when to use this option and when not to?

If so, do Bernhard and/or Rob prefer the #ifdef
CONFIG_FEATURE_CLEAN_UP/#endif style or the if (ENABLE_FEATURE_CLEAN_UP)
style? Or does it matter? Examples of both are all over the code.

Thanks

E

-- 
Erik Hovland
mail: erik AT hovland DOT org
web: http://hovland.org/
PGP/GPG public key available on request



More information about the busybox mailing list