On Mon, Aug 4, 2025 at 12:32 PM Roberto A. Foglietta <[email protected]> wrote: > On Mon, 4 Aug 2025 at 12:12, Denys Vlasenko <[email protected]> wrote: > > On Mon, Aug 4, 2025 at 11:43 AM Roberto A. Foglietta > > <[email protected]> wrote: > > > > 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? ;-) > > > > The free is called in the parent, after vforked child execs or exits. > > That is another process which made CoW of the stack of the previous.
It's not COWed. vfork does not duplicate address space. Whatever was allocated in the child, was also allocated in the parent (because it's the same address space). > Why then does the child termination leaks memory? Because the parent attempted to free that memory by calling free(to_free), but the child (as I explained) did not store the pointer in need of freeing into to_free. to_free remained NULL, and parent didn't free anything. > Hence this approach is correct, isn't it? > > + #if ENABLE_FEATURE_CLEAN_UP > + free (ptr_to_globals); > + #endif The correct fix is to specify the pointer in question as "volatile" variable, so that gcc stops making assumptions about its liveness. _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
