[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/bin/ps
Date: Wed, 11 Sep 2019 21:13:24 +0200
From: Kamil Rytarowski <n54%gmx.com@localhost>
| We have got even fixups in libc for such "nonsense" cases.
Why? In 99% (or more) of libc the fixes are relevant, as those functions
can be called over & over and so should not be discarding memory.
atexit() is a somewhat special case - if simply calling it leaks, then that
ought be fixed, if the "leak" is just the data struct used to keep track
of what needs to be run when the program ends, then not freeing that
stuff is 100% harmless, and there's no point "fixing" it.
| A workaround would be ...
I don't know anything about the sanatisers so can't comment on what
should be done with them.
But if you were ever to test sh (and I would guess not just /bn/sh, but
any shell) for this kind of thing, you'd find that at exit none of the
user's (or shell's) variables have been freed, the hash table that
associates command names with the located paths is not freed, aliases are
not freed, nor defined functions, shell history, key bindings for libedit,
defined traps, ... and probably much more I cannot remember just now,
including (if the shell exits via a call to the exit builtin somewhere
in the script) the internal code tree that is currently being evaluated.
It would be a lot of code to go free all of that, it would slow down
shell exit, and all for no benefit at all, as when _exit() eventually
gets called, everything is returned to the kernel, nothing is lost.
Further, other than that the shell is exiting, the data structs in
question all need to be retained, so nothing in them can be freed any time
before the shell exits (obviously other than when that data is being
updated, and the old data is freed).
Does anyone really want to make the shell, or other programs, run slower
just so someone can say that all memory was nicely (but pointlessly) freed
before exit ?
Main Index |
Thread Index |