On Sun, 3 Aug 2025 at 23:27, Denys Vlasenko <vda.li...@googlemail.com> wrote: > > On Sun, Aug 3, 2025 at 9:33 PM Harry Eaton <bump...@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- _______________________________________________ busybox mailing list busybox@busybox.net https://lists.busybox.net/mailman/listinfo/busybox
