On Thu, Aug 7, 2025 at 8:14 PM Harry Eaton <[email protected]> wrote: > > It turns out that on my actual target, declaring to_free as volatile does NOT > solve the leak problem. > > Here is the diff of the hush.c source between my previous solution (putting > to_free in the globals, which does solve the leak) and the volatile attempt > at the same (I left it declared in the definition of the global struct in > both cases): > > --- Vhush.c 2025-08-07 13:13:42.863447663 -0400 > +++ Ghush.c 2025-08-07 13:53:53.171455825 -0400 > @@ -7731,8 +7732,8 @@ > pid_t pid; > int channel[2]; > # if !BB_MMU > - volatile char ** to_free = NULL; > -// G.to_free = NULL; > +// volatile char ** to_free = NULL; > + G.to_free = NULL; > # endif
You made a wrong thing volatile. The pointer (to pointer to char) has to be volatile, not the data it points to. Please try current git: # if !BB_MMU - char **to_free = NULL; + /* _volatile_ pointer to "char*". + * Or else compiler can peek from inside re_execute_shell() + * and see that this pointer is a local var (i.e. not globally visible), + * and decide to optimize out the store to it. Yes, + * it was seen in the wild. + */ + char * *volatile to_free = NULL; # endif (To read the syntax more easily, see "*volatile" as an indivisible unit which means "volatile pointer", analogous to "*" which means "pointer"). _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
