Hello all, Hope this finds you well. Trying to run config2help it segfaults.
Pulling the source from Toybox and building with gcc -0 -g -Wall That too segfaults so I think I have the latest version (the source seems to be mostly contained in a single file scripts/config2help.c). Google(ing) turned up many hits of fairly recent (circa 2018+) conversations on or about this same complaint. Digging into the logic of the code, it seems there may be some cruft/age to the logic and some mishandling of pointer use AFTER free (as shown by valgrind). In "some" aforementioned Google(ing) complaints seemed so stem from an update of their glibc. I can attest to the same as my builds were going smoothly until I did an apt update; apt upgrade . My point. 1.) Is the latest source (hopefully) with a fix for the "use after free" segfault in " https://github.com/landley/toybox/blob/master/scripts/config2help.c" 2.) Following the code in 1.) it seems that some of the logic may be more complex than the input would suggest. The code inspecting the generated "sym" list while looping through the entries in ".config" and setting sym->enabled ... indicates to me that ".config" controls which "processed" "symbols" get spit-out as "#defined HELPXXX". Is that true and or intended? The flow seems to indicate that multiple "symbols" of the same "name" may/do exist over multiple Config.in (and "sourced") files; and "duplicates" need/should to be "collated". In practice; I haven't seen "duplicate" "symbols" and wonder if mashing "duplicates" together wouldn't lead to probable error/nonsense. 3.) If the above are/is true; would a rewrite with less "dependencies" and a "clean" valgrind run be at-all welcome? In closing, am I just lost in the woods? If so, could someone spin me around and nudge me in the correct direction? Thanks for your attention, James
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net