GNU bug report logs - #79328
expr: memory not freed before program exit(memory leak)

Previous Next

To reply to this bug, email your comments to 79328 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: yubiao hu <huyubiaox <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: expr: memory not freed before program exit(memory leak)
Date: Thu, 28 Aug 2025 14:44:45 +0800

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

Package: coreutils
Version: 9.4
Severity: normal

I was trying to build coreutils with ASan, and found a memory leak in expr.

When running:
 expr length "hello"

Output:
=================================================================
==755058==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0xffff7f7a2524 in __interceptor_malloc
../../../../libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0xaaaacd31f4c8 in xmalloc ../lib/xmalloc.c:45
    #2 0xaaaacd2a0dd4 in int_value ../src/expr.c:369
    #3 0xaaaacd2a0dd4 in eval6 ../src/expr.c:714
    #4 0xaaaacd2a0dd4 in eval6 ../src/expr.c:694
    #5 0xaaaacd2a4f44 in eval5 ../src/expr.c:786
    #6 0xaaaacd2a5320 in eval4 ../src/expr.c:817
    #7 0xaaaacd2a595c in eval3 ../src/expr.c:856
    #8 0xaaaacd2a5dbc in eval2 ../src/expr.c:886
    #9 0xaaaacd2a72e0 in eval1 ../src/expr.c:965
    #10 0xaaaacd2a7874 in eval ../src/expr.c:996
    #11 0xaaaacd29d3e0 in main ../src/expr.c:352

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

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

From: Collin Funk <collin.funk1 <at> gmail.com>
To: yubiao hu <huyubiaox <at> gmail.com>
Cc: 79328 <at> debbugs.gnu.org
Subject: Re: bug#79328: expr: memory not freed before program exit(memory leak)
Date: Thu, 28 Aug 2025 01:08:35 -0700

Hi,

yubiao hu <huyubiaox <at> gmail.com> writes:

> Package: coreutils
> Version: 9.4
> Severity: normal
>
> I was trying to build coreutils with ASan, and found a memory leak in expr.
>
> When running:
>  expr length "hello"
>
> Output:
> =================================================================
> ==755058==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
>     #0 0xffff7f7a2524 in __interceptor_malloc
> ../../../../libsanitizer/asan/asan_malloc_linux.cpp:69
>     #1 0xaaaacd31f4c8 in xmalloc ../lib/xmalloc.c:45
>     #2 0xaaaacd2a0dd4 in int_value ../src/expr.c:369
>     #3 0xaaaacd2a0dd4 in eval6 ../src/expr.c:714
>     #4 0xaaaacd2a0dd4 in eval6 ../src/expr.c:694
>     #5 0xaaaacd2a4f44 in eval5 ../src/expr.c:786
>     #6 0xaaaacd2a5320 in eval4 ../src/expr.c:817
>     #7 0xaaaacd2a595c in eval3 ../src/expr.c:856
>     #8 0xaaaacd2a5dbc in eval2 ../src/expr.c:886
>     #9 0xaaaacd2a72e0 in eval1 ../src/expr.c:965
>     #10 0xaaaacd2a7874 in eval ../src/expr.c:996
>     #11 0xaaaacd29d3e0 in main ../src/expr.c:352

I recommend running the following in your shell before testing with
address sanitizer:

    $ export ASAN_OPTIONS="detect_leaks=0

Most (all?) of the programs in Coreutils will not free memory before
exit, since it just takes extra time for no benefit.

Also, I expect most other GNU programs to behave this way. Since it is
the behavior recommended in the GNU Coding Standards [1].

Thanks,
Collin

[1] https://www.gnu.org/prep/standards/standards.html#Memory-Usage

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Collin Funk <collin.funk1 <at> gmail.com>, yubiao hu <huyubiaox <at> gmail.com>
Cc: 79328 <at> debbugs.gnu.org
Subject: Re: bug#79328: expr: memory not freed before program exit(memory leak)
Date: Thu, 28 Aug 2025 06:48:24 -0700

On 2025-08-28 01:08, Collin Funk wrote:
> Most (all?) of the programs in Coreutils will not free memory before
> exit, since it just takes extra time for no benefit.

Not only does it take extra time (and sometimes even space!), it makes 
the programs slightly less reliable because if there are bugs elsewhere 
the calls to 'free' can have undefined behavior. And this makes for more 
maintenance burden, since developers therefore have to verify that these 
other bugs cannot occur.

The idea that programmers ought to carefully free everything just before 
exit, merely to pacify a leak sanitizer, is misguided and counterproductive.

Previous Next

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