bug#48189: ginstall: memory leak when omitting a directory

[Pádraig Brady]

On 03/05/2021 15:13, TU Haoxin wrote:
> Dear all.
>
> We are a team from Singapore Management University and we wrote a symbolic execution tool based on 
> KLEE recently. After running the Coreutils packages(the newest released version, 8.32), we found 
> some interesting issues(most are reported as "detected memory leaks" and one is reported 
> "stack-overflow" by AddressSanitizer). Due to this is our first time reporting a 
> potential bug in this community, we are not sure these bugs found by our tool are useful. 
> Therefore, we don't want to waste your precious time, and here we just want to report one bug to 
> you. If you confirm this is a real bug and could be helpful to you, we will file other issues then. 
> Thank you very much!
>
> The following are instructions to help reproduce the issue:
>
> $ginstall "/" "/" "--"
> ./ginstall: omitting directory '/'
>
> =================================================================
> ==2394==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 80 byte(s) in 1 object(s) allocated from:
>      #0 0x492bcf in __interceptor_malloc 
> ../../../../libsanitizer/asan/asan_malloc_linux.cpp:145
>      #1 0x4ef365 in hash_initialize ../lib/hash.c:605
>      #2 0x4e1362 in dest_info_init ../src/copy.c:1740
>      #3 0x4d98d7 in main ../src/install.c:1050
>      #4 0x7feef2e9abf6 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)
>
> Indirect leak of 1264 byte(s) in 1 object(s) allocated from:
>      #0 0x492d87 in __interceptor_calloc 
> ../../../../libsanitizer/asan/asan_malloc_linux.cpp:154
>      #1 0x50119b in rpl_calloc ../lib/calloc.c:65
>      #2 0x4ef45c in hash_initialize ../lib/hash.c:626
>      #3 0x4e1362 in dest_info_init ../src/copy.c:1740
>      #4 0x4d98d7 in main ../src/install.c:1050
>      #5 0x7feef2e9abf6 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)
>
> SUMMARY: AddressSanitizer: 1344 byte(s) leaked in 2 allocation(s).
>
> $./ginstall --version
> install (GNU coreutils) 8.32
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by David MacKenzie.
>
> $uname -a
> Linux jlx-super-server 5.4.0-72-generic #80~18.04.1-Ubuntu SMP Mon Apr 12 
> 23:26:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>
> The configure option is "../configure --disable-nls CFLAGS="-fsanitize=address -static-libasan 
> -g" CXXFLAGS="-fsanitize=address -static-libasan -g"
>
> By the way, may I ask if the issues reported by AddressSanitizer are really 
> bugs worth reporting? I am not sure whether such a tool will report some 
> false-positive cases.
>
> Thanks again for your time and help!

This isn't a real leak as the program terminates after return from main().
Now for asan/valgrind to be useful we should avoid these "definitely lost"
cases.  The attached does this for these hash structures at least,
by consistently freeing them in dev mode (with "lint" defined).

Note if we exit() from the main() functions, rather than using return,
then valgrind recognizes the termination case, and does not flag this
as definitely lost.  The main() functions were changed from using exit()
to return in cleanup associated with the support for the single binary build:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=8defcee49
Perhaps we might consider adjusting that bacak, to something more general
that valgrind may infer program termination from?

Marking this as done,
cheers,
Pádraig

coreutils-hash-cleanup.patch
Description: Text Data