ld.mcld valgrind issues creating shared library

[GoogleCodeExporter]

What steps will reproduce the problem?
1.ld.mcld produces lot of errors trying to run valgrind on simple testcase.

Testcase :-

$cat b.sh
cat > 1.c << \!
int a = 10;
!

gcc -m32 -c -fPIC 1.c -o 1.o
valgrind ld.mcld -shared 1.o -march x86 -o lib1.so

What is the expected output? What do you see instead?

No errors from valgrind is what we would want to see.

You get 

=32650== More than 1000 different errors detected.  I'm not reporting any more.
==32650== Final error counts will be inaccurate.  Go fix your program!
==32650== Rerun with --error-limit=no to disable this cutoff.  Note
==32650== that errors may occur in your program without prior warning from
==32650== Valgrind, because errors are no longer being displayed.

What version of the product are you using? On what operating system?

Latest trunk version.

Please provide any additional information below.

$valgrind --version
valgrind-3.8.1 (latest version)

Original issue reported on code.google.com by shanka...@gmail.com on 15 May 2013 at 12:31

[GoogleCodeExporter]

This is not a helpful bug report. At the very least include what errors it is 
reporting.

Original comment by joerg.sonnenberger@googlemail.com on 9 Aug 2013 at 1:55

[GoogleCodeExporter]

attached log file.

Original comment by shanka...@gmail.com on 9 Aug 2013 at 6:26

Attachments:

• log.txt.gz

[GoogleCodeExporter]

This looks like a valgrind report on an optimized binary. Most of those are 
false positives inside glibc. I've fixed on bug and now only see a non-critical 
memory leak when linking a small C++ program.

Original comment by joerg.sonnenberger@googlemail.com on 9 Aug 2013 at 7:36

[GoogleCodeExporter]

I dont see any errors though when I run valgrind against clang or ld or gold 
for that matter.

<snip from clang> 

$ valgrind clang -c 1.c
==5293== Memcheck, a memory error detector
==5293== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==5293== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==5293== Command: clang -c 1.c
==5293==
==5293==
==5293== HEAP SUMMARY:
==5293==     in use at exit: 48 bytes in 2 blocks
==5293==   total heap usage: 396 allocs, 394 frees, 89,156 bytes allocated
==5293==
==5293== LEAK SUMMARY:
==5293==    definitely lost: 0 bytes in 0 blocks
==5293==    indirectly lost: 0 bytes in 0 blocks
==5293==      possibly lost: 0 bytes in 0 blocks
==5293==    still reachable: 48 bytes in 2 blocks
==5293==         suppressed: 0 bytes in 0 blocks
==5293== Rerun with --leak-check=full to see details of leaked memory
==5293==
==5293== For counts of detected and suppressed errors, rerun with: -v
==5293== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

Original comment by shanka...@gmail.com on 9 Aug 2013 at 8:15

[GoogleCodeExporter]

Hi Shankar,
Do you still see this issue? Running valgrind w/ ToT 
(764ada7f1cbeadd93f1a6d6a78a288e3c011d9fb), I get

$ valgrind --leak-check=full ld.mcld -shared 1.o -march x86 -o lib1.so
==27794== Memcheck, a memory error detector
==27794== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==27794== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==27794== Command: ld.mcld -shared 1.o -march x86 -o lib1.so
==27794== 
==27794== 
==27794== HEAP SUMMARY:
==27794==     in use at exit: 121 bytes in 5 blocks
==27794==   total heap usage: 3,746 allocs, 3,741 frees, 740,196 bytes allocated
==27794== 
==27794== LEAK SUMMARY:
==27794==    definitely lost: 0 bytes in 0 blocks
==27794==    indirectly lost: 0 bytes in 0 blocks
==27794==      possibly lost: 0 bytes in 0 blocks
==27794==    still reachable: 121 bytes in 5 blocks
==27794==         suppressed: 0 bytes in 0 blocks
==27794== Reachable blocks (those to which a pointer was found) are not shown.
==27794== To see them, rerun with: --leak-check=full --show-reachable=yes
==27794== 
==27794== For counts of detected and suppressed errors, rerun with: -v
==27794== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

Original comment by pete.c...@gmail.com on 30 Sep 2013 at 3:04

[GoogleCodeExporter]

Hi Shankar,

Please re-open this issue if you still find other leaks.

Original comment by pete.c...@gmail.com on 3 Oct 2013 at 8:44

• Changed state: Done