[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pádraig Brady
Subject: bug#48189: ginstall: memory leak when omitting a directory
Date: Mon, 3 May 2021 18:51:43 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Thunderbird/84.0

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 
     #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 

Indirect leak of 1264 byte(s) in 1 object(s) allocated from:
     #0 0x492d87 in __interceptor_calloc 
     #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 

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:
Perhaps we might consider adjusting that bacak, to something more general
that valgrind may infer program termination from?

Marking this as done,

Attachment: coreutils-hash-cleanup.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]