|
From: Andreas F. <and...@di...> - 2004-06-23 07:06:35
|
Hi,
this sounds like memory allocated from within the c++ standard library.
I know versions of GCC prior to 3.4.0 would define guard variables for
things like std::cout when you included <iostream>. These could easily
hold on to bits of memory for the entire length of the program.
Try adding --num-callers=3D20 to your command line to see if the
allocation really originates from the c++ runtime, but it seems like the
only way in the example below.
Regards,
Andreas
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of David
Hubner
Sent: den 23 juni 2004 03:39
To: val...@li...
Subject: [Valgrind-users] Valgrind and gcc 3.4
Hi,
When i #include <iostream> i get a definitely lost memleak. Is this
natural, a bug in valgrind, a bug in gcc 3.4.0?? Anyone know?
----------------------------------
Program:
#include <iostream>
int main(){}
----------------------------------
valgrind:
hubnerd:~/soul/src/src$ valgrind --tool=3Dmemcheck --leak-check=3Dyes
./a.out =3D=3D604=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D604=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D604=3D=3D Using valgrind-2.1.1, a program supervision framework =
for
x86-linux.
=3D=3D604=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian =
Seward.
=3D=3D604=3D=3D For more details, rerun with: -v =3D=3D604=3D=3D =
=3D=3D604=3D=3D Conditional
jump or move depends on uninitialised value(s)
=3D=3D604=3D=3D at 0x3C00160C: elf_dynamic_do_rel.4 (do-rel.h:69)
=3D=3D604=3D=3D by 0x3C0018A9: _dl_start (rtld.c:189)
=3D=3D604=3D=3D by 0x3C0013B5: (within /lib/ld-2.2.5.so)
=3D=3D604=3D=3D
=3D=3D604=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D604=3D=3D at 0x3C001614: elf_dynamic_do_rel.4 (do-rel.h:88)
=3D=3D604=3D=3D by 0x3C0018A9: _dl_start (rtld.c:189)
=3D=3D604=3D=3D by 0x3C0013B5: (within /lib/ld-2.2.5.so)
=3D=3D604=3D=3D
=3D=3D604=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D604=3D=3D at 0x3C00164B: elf_dynamic_do_rel.4 (do-rel.h:97)
=3D=3D604=3D=3D by 0x3C0018A9: _dl_start (rtld.c:189)
=3D=3D604=3D=3D by 0x3C0013B5: (within /lib/ld-2.2.5.so)
=3D=3D604=3D=3D
=3D=3D604=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D604=3D=3D at 0x3C008BBF: elf_dynamic_do_rel.4 (do-rel.h:55)
=3D=3D604=3D=3D by 0x3C008E8A: _dl_relocate_object (dl-reloc.c:155)
=3D=3D604=3D=3D by 0x3C002091: dl_main (rtld.c:1086)
=3D=3D604=3D=3D by 0x3C00C841: _dl_sysdep_start
(../sysdeps/generic/dl-sysdep.c:208)
=3D=3D604=3D=3D
=3D=3D604=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D604=3D=3D at 0x3C008BC3: elf_dynamic_do_rel.4 (do-rel.h:58)
=3D=3D604=3D=3D by 0x3C008E8A: _dl_relocate_object (dl-reloc.c:155)
=3D=3D604=3D=3D by 0x3C002091: dl_main (rtld.c:1086)
=3D=3D604=3D=3D by 0x3C00C841: _dl_sysdep_start
(../sysdeps/generic/dl-sysdep.c:208)
=3D=3D604=3D=3D
=3D=3D604=3D=3D ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 =
from 0)
=3D=3D604=3D=3D malloc/free: in use at exit: 80 bytes in 2 blocks.
=3D=3D604=3D=3D malloc/free: 2 allocs, 0 frees, 80 bytes allocated.
=3D=3D604=3D=3D For counts of detected errors, rerun with: -v =
=3D=3D604=3D=3D searching
for pointers to 2 not-freed blocks.
=3D=3D604=3D=3D checked 2409280 bytes.
=3D=3D604=3D=3D
=3D=3D604=3D=3D
=3D=3D604=3D=3D 16 bytes in 1 blocks are definitely lost in loss record =
1 of 2
=3D=3D604=3D=3D at 0x3C01E38D: malloc (vg_replace_malloc.c:105)
=3D=3D604=3D=3D by 0x3C01EBDB: realloc (vg_replace_malloc.c:154)
=3D=3D604=3D=3D by 0x3C1AE947: argz_append (argz-append.c:30)
=3D=3D604=3D=3D by 0x3C15B7F4: __newlocale (newlocale.c:100)
=3D=3D604=3D=3D
=3D=3D604=3D=3D LEAK SUMMARY:
=3D=3D604=3D=3D definitely lost: 16 bytes in 1 blocks.
=3D=3D604=3D=3D possibly lost: 0 bytes in 0 blocks.
=3D=3D604=3D=3D still reachable: 64 bytes in 1 blocks.
=3D=3D604=3D=3D suppressed: 0 bytes in 0 blocks.
=3D=3D604=3D=3D Reachable blocks (those to which a pointer was found) =
are not
shown.
=3D=3D604=3D=3D To see them, rerun with: --show-reachable=3Dyes
--
David Hubner
hu...@bt...
"If you are going through hell, keep going."
- Sir Winston Churchill (1874-1965)
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
self defense, top technical experts, no vendor pitches, unmatched
networking opportunities. Visit www.blackhat.com
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Joseph T. <tu...@gm...> - 2004-06-26 19:35:50
Attachments:
test-numcallers20.err
test.err
|
Andreas + David, I am getting these messages too, under Gentoo's GCC 3.4. > Try adding --num-callers=20 to your command line to see if the > allocation really originates from the c++ runtime, but it seems like the > only way in the example below. I don't understand, what should I be looking for when adding this parameter? Attached is the stdout+stderr logs. test.err is with the original command-line. test-numcallers20.err is with --num-callers=20 Joseph -- http://www.cs.nyu.edu/~turian/ |
|
From: Tom H. <th...@cy...> - 2004-06-26 20:18:24
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> I am getting these messages too, under Gentoo's GCC 3.4.
>
> > Try adding --num-callers=20 to your command line to see if the
> > allocation really originates from the c++ runtime, but it seems like the
> > only way in the example below.
>
> I don't understand, what should I be looking for when adding this parameter?
>
> Attached is the stdout+stderr logs. test.err is with the original
> command-line. test-numcallers20.err is with --num-callers=20
I'm not clear what the problem here - is it the jump depends on
uninitialised value warnings from ld.so that you're worried about?
If so then it is likely just the normal _dl_relocate ones which
you always get but because your ld.so looks like it is stripped
the suppressions won't be kicking in.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Joseph T. <tu...@gm...> - 2004-06-26 21:51:51
|
Tom, > I'm not clear what the problem here - is it the jump depends on > uninitialised value warnings from ld.so that you're worried about? I'm not sure what David's concern was. I have no prior experience with valgrind, so I was wondering: Is this error message normal/expected? If not, how do I resolve this? > If so then it is likely just the normal _dl_relocate ones which > you always get but because your ld.so looks like it is stripped > the suppressions won't be kicking in. I don't think my ld.so is stripped, I didn't compile it with "-s". But there aren't debugging symbols. Joseph -- http://www.cs.nyu.edu/~turian/ |
|
From: Tom H. <th...@cy...> - 2004-06-26 23:15:34
|
In message <4da...@ma...>
Joseph Turian <tu...@gm...> wrote:
> > I'm not clear what the problem here - is it the jump depends on
> > uninitialised value warnings from ld.so that you're worried about?
>
> I'm not sure what David's concern was.
>
> I have no prior experience with valgrind, so I was wondering:
> Is this error message normal/expected?
> If not, how do I resolve this?
There is a known 'optimisatiom' in ld.so that causes valgrind to
emit warnings. Those warnings are normally suppressed by the default
suppressions file.
I don't know if that's what you're seeing because there were no
nanes in the trace, so I was just guesing.
> > If so then it is likely just the normal _dl_relocate ones which
> > you always get but because your ld.so looks like it is stripped
> > the suppressions won't be kicking in.
>
> I don't think my ld.so is stripped, I didn't compile it with "-s". But
> there aren't debugging symbols.
You shouldn't need debugging symbols, but the complete lack of
names in the trace from valgrind suggests that you didn't have
any symbols at all other that the dynamic symbol table that any
shared object will have.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|