What's the use of FEATURE_CLEANUP ?

Rob Landley rob at landley.net
Mon Dec 19 23:56:19 UTC 2005

On Monday 19 December 2005 12:36, Larry Doolittle wrote:
> Ignacio -
> On Mon, Dec 19, 2005 at 07:00:21PM +0100, Ignacio Garc?a P?rez wrote:
> > In which cases it is actually useful to do a cleanup (deallocate memory,
> > close handles) ?.
> I believe the rationale for FEATURE_CLEANUP is to facilitate
> memory-leak checkups with e.g., dmalloc.  It flags memory
> locations that are _supposed_ to be left dangling at exit,
> so you can more easily find those that are _accidentally_
> left dangling at exit.

I've always been a little unclear on the difference, myself.  Either we're 
relying on exit() to clean up everything, or we're not.  What's the middle 
ground for?

Right now, running busybox without fork/exit isn't really supported.  It's 
been sort of made to work for a very restricted subset of applets in 
carefully controlled situations, but expect to do a lot of testing if you try 
that, and lots of applets you just can't use.

For most users, FEATURE_CLEANUP is useless bloat.  And until we do NOFORK 
annotation of applets and figure out what to do about all the exit cases in 
libbb (and just about _everything_ in there exits on error, including 
bb_xfopen() and xmalloc()), it's going to remain useless bloat.

By the way, it's possible it will _still_ be useless bloat even after an 
attempt at dealing with it.  In theory we could have all malloc and open 
calls maintain linked lists that we checkpoint on pseudo-fork (along with 
calling setjmp) and then iterate through and free/close on pseudo-exit before 
calling longjmp().

In _practice_, how is this smaller than just having your kernel implement a 
working fork if you need it?  To do it right we'd also have to wrap all sorts 
of other things like mmap and chdir, and what about environment variables, 
and how the _heck_ do we get suid back for those applets that need it...?

And you wonder why I haven't put much effort into this?  If you want extensive 
infrastructure to compensate for a massively deficient kernel, why not put it 
in your C library instead of trying to shoehorn it into busybox?  Currently, 
the _only_ applets that's are candidates for NOFORK are "echo" and "test"...

>      - Larry

Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

More information about the busybox mailing list