SOLVED Re: Memory leak in hush with NOMMU busybox-1.37.0

[Roberto A. Foglietta]

On Sun, 3 Aug 2025 at 23:27, Denys Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Sun, Aug 3, 2025 at 9:33 PM Harry Eaton <bumpelo at gmail.com> wrote:

[...]

> > The other leak is difficult to explain "exactly". It mostly doesn't happen on a system with a real MMU, but it happens reliably on my actual target which has only 1 processor and no MMU. If you run the new hunt_leaktool.sh on the attached "output.on_target.txt" it will show the leak. If you look carefully at the output file, the free() is happening, but it is always 0, so it doesn't free anything.
>
> I reproduced it. It's overzealous optimization. gcc just doesn't store
> the pointer into *to_free,
> because it can see that in all callers of the static function where
> the store is done, the address
> points to a local (on-stack) variable, therefore this variable is not
> visible to any other thread,
> and also the store can't alias with any global variables. And we are
> in a NORETURN function,
> so gcc can see the entire execution path until the program "ends"
> So, the store looks "dead" to gcc and it eliminates it.
>
> I discovered this when an added debugging statement took the address
> of the variable and passed
> it to a printf. The conclusion that the store is "dead" become invalid
> and the leak disappeared
> (gcc no longer eliminated the store).

Therefore a free() instead of a printf() that calls such a pointer
variable, solves both the problems at once: free it, and call it into
the scope avoiding the gcc over-optimisation. Right? ;-)

Best regards, R-