Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 453089 - ld(1) memory leak
Summary: ld(1) memory leak
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: binutils
Version: 5.1
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Denys Vlasenko
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-27 07:46 UTC by masanari iida
Modified: 2008-12-09 18:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-12-09 18:22:03 UTC


Attachments (Terms of Use)

Description masanari iida 2008-06-27 07:46:29 UTC
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 15:37:16 UTC
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 18:22:03 UTC
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.