GNU bug report logs - #48189
ginstall: memory leak when omitting a directory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48189 in the body.
You can then email your comments to 48189 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: TU Haoxin <haoxintu.2020 <at> phdcs.smu.edu.sg>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: ginstall: memory leak when omitting a directory
Date: Mon, 3 May 2021 14:13:06 +0000

[Message part 1 (text/plain, inline)]

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!


Best regards,
Haoxin

[Message part 2 (text/html, inline)]

Message #10 received at 48189-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: TU Haoxin <haoxintu.2020 <at> phdcs.smu.edu.sg>
Cc: 48189-done <at> debbugs.gnu.org
Subject: Re: bug#48189: ginstall: memory leak when omitting a directory
Date: Mon, 3 May 2021 10:40:24 -0700

That one's not a real bug. 'install' is exiting, rather than calling 
'free' a couple of times just before exiting; calling 'free' would 
simply chew up runtime resources for no reason other than to pacify 
AddressSanitizer. So I'll close this particular bug report.

Most memory leaks found by AddressSanitizer in coreutils are false 
alarms. That being said, if you find one that isn't a false alarm we'd 
be interested in hearing about it. Stack overflows are also good to 
report too, except for tricky user-specified regular expressions (which 
require exponential resources in the worst case, no matter what the 
implementation is).

Message #13 received at 48189-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: TU Haoxin <haoxintu.2020 <at> phdcs.smu.edu.sg>, 48189-done <at> debbugs.gnu.org
Subject: Re: bug#48189: ginstall: memory leak when omitting a directory
Date: Mon, 3 May 2021 18:51:43 +0100

[Message part 1 (text/plain, inline)]

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 (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.