Bug 453089 - ld(1) memory leak
ld(1) memory leak
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: binutils (Show other bugs)
5.1
All Linux
low Severity low
: rc
: ---
Assigned To: Denys Vlasenko
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-27 03:46 EDT by masanari iida
Modified: 2008-12-09 13:22 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-09 13:22:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description masanari iida 2008-06-27 03:46:29 EDT
Description of problem:
ld(1) seemed to forget to free some blocks,
according to valgrind.

Version-Release number of selected component (if applicable):

# rpm -qf /usr/bin/ld
binutils-2.17.50.0.6-2.el5

How reproducible:
always

Steps to Reproduce:
1. Install valgrind from Fedora9.
2. Run # valgrind --tool=memcheck --leak-check=full ld

  
Actual results:

ld: no input files
==16665==
==16665== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)
==16665== malloc/free: in use at exit: 37,322 bytes in 455 blocks.
==16665== malloc/free: 492 allocs, 37 frees, 40,285 bytes allocated.
==16665== For counts of detected errors, rerun with: -v
==16665== searching for pointers to 455 not-freed blocks.
==16665== checked 126,928 bytes.
==16665==
==16665== 2,206 bytes in 2 blocks are definitely lost in loss record 3 of 8
==16665==    at 0x40055E2: realloc (vg_replace_malloc.c:306)
==16665==    by 0x500CC4: xrealloc (in /usr/lib/libbfd-2.17.50.0.6-2.el5.so)
==16665==    by 0x8066331: (within /usr/bin/ld)
==16665==    by 0x804F932: (within /usr/bin/ld)
==16665==    by 0x805D8AB: (within /usr/bin/ld)
==16665==    by 0x35ADEB: (below main) (in /lib/libc-2.5.so)
==16665==
==16665==
==16665== 2,376 bytes in 13 blocks are definitely lost in loss record 4 of 8
==16665==    at 0x40054E5: malloc (vg_replace_malloc.c:149)
==16665==    by 0x500D79: xmalloc (in /usr/lib/libbfd-2.17.50.0.6-2.el5.so)
==16665==    by 0x804F80E: (within /usr/bin/ld)
==16665==    by 0x805D8AB: (within /usr/bin/ld)
==16665==    by 0x35ADEB: (below main) (in /lib/libc-2.5.so)
==16665==
==16665== LEAK SUMMARY:
==16665==    definitely lost: 4,582 bytes in 15 blocks.  <==
==16665==      possibly lost: 0 bytes in 0 blocks.
==16665==    still reachable: 32,740 bytes in 440 blocks.
==16665==         suppressed: 0 bytes in 0 blocks.
==16665== Reachable blocks (those to which a pointer was found) are not shown.
==16665== To see them, rerun with: --leak-check=full --show-reachable=yes


Expected results:
No memory leak.

Additional info:
Comment 1 Denys Vlasenko 2008-07-18 11:37:16 EDT
Is this leak becoming much bigger if you link some big program? Can you post the
numbers and a reproducible testcase?
Comment 2 Denys Vlasenko 2008-12-09 13:22:03 EST
4k of leaked malloc memory does not look big enough to hunt down. ld is not a long running server program like webserver, where this could be important.

Note You need to log in before you can comment on or make changes to this bug.