Date: Wed, 11 Sep 2019 21:13:24 +0200 From: Kamil Rytarowski <n...@gmx.com> Message-ID: <6c853bc7-6510-459e-d451-51f988617...@gmx.com>
| 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 ? kre