|
From: Tao T W. <wan...@cn...> - 2006-04-29 07:39:53
|
I built valgrind-3.1.1 in SLES10-Beta10-i386 (gcc-4.1.0, glibc-2.4) and
wrote a very simple program to test valgrind:
#include <stdio.h>
#include <stdlib.h>
int main()
{
char *ptr1, *ptr2;
int n = 100000;
ptr1 = malloc(n);
ptr2 = malloc(n);
return 0;
}
Then I run the program with the command "valgirnd --tool=memcheck
--leak-check=yes ./memcheck", got the following outputs:
==9505== Memcheck, a memory error detector.
==9505== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==9505== Using LibVEX rev 1575, a library for dynamic binary translation.
==9505== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==9505== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==9505== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==9505== For more details, rerun with: -v
==9505==
==9505==
==9505== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1)
==9505== malloc/free: in use at exit: 200,000 bytes in 2 blocks.
==9505== malloc/free: 2 allocs, 0 frees, 200,000 bytes allocated.
==9505== For counts of detected errors, rerun with: -v
==9505== searching for pointers to 2 not-freed blocks.
==9505== checked 56,584 bytes.
==9505==
==9505== 100,000 bytes in 1 blocks are definitely lost in loss record 1 of
2
==9505== at 0x4021259: malloc (vg_replace_malloc.c:149)
==9505== by 0x8048424: main (in /home/wangttao/valgrind/memcheck)
==9505==
==9505==
==9505== 100,000 bytes in 1 blocks are possibly lost in loss record 2 of 2
==9505== at 0x4021259: malloc (vg_replace_malloc.c:149)
==9505== by 0x8048416: main (in /home/wangttao/valgrind/memcheck)
==9505==
==9505== LEAK SUMMARY:
==9505== definitely lost: 100,000 bytes in 1 blocks.
==9505== possibly lost: 100,000 bytes in 1 blocks.
==9505== still reachable: 0 bytes in 0 blocks.
==9505== suppressed: 0 bytes in 0 blocks.
==9505== Reachable blocks (those to which a pointer was found) are not
shown.
==9505== To see them, rerun with: --show-reachable=yes
It's very strange. In the source code, ptr1 and ptr2 are exactly the same,
but valgrind reported different memory leaks, one is "definitely lost" and
the other is "possibly lost"(The correct result should be "definitely
lost" for both ptr1 and ptr2). If I change "n" from "100000" to "10000",
then everything is ok, both ptr1 and ptr2 are reported as "definitely
lost".
Tried on SLES10-Beta10-x86_64, it's ok. Rebuilt valgrind in
SLES9-SP3(gcc-3.3.3, glibc-2.3) and run the same test, it's also ok.
Any ideas on why it only fails in SLES10-Beta10-ia32? Is it because of
glibc-2.4?
---
Thanks,
Wang Tao |
|
From: Brad H. <br...@fr...> - 2006-04-30 01:53:12
|
On Saturday 29 April 2006 17:39 pm, Tao T Wang wrote: > Tried on SLES10-Beta10-x86_64, it's ok. Rebuilt valgrind in > SLES9-SP3(gcc-3.3.3, glibc-2.3) and run the same test, it's also ok. > > Any ideas on why it only fails in SLES10-Beta10-ia32? Is it because of > glibc-2.4? I'd be more suspicious of variations in what the compiler is doing. What fl= ags=20 (especially, what optimisations) are you doing in each case? Maybe you coul= d=20 look at the assembler output and try to figure out what is different? Brad |
|
From: Paul P. <ppl...@gm...> - 2006-04-30 03:46:23
|
Tao T Wang wrote:
> It's very strange.
Not at all.
> In the source code, ptr1 and ptr2 are exactly the same, but valgrind
> reported different memory leaks, one is "definitely lost" and the
> other is "possibly lost"
You don't understand what "possibly lost" means.
If you did, you would not be surprized.
What it means is that there is a reachable pointer (or data that looks like
a pointer) somewhere, which happens to point 'inside' (but not at the
beginning)
of the block. The bigger the block, the more there is a chance that
there will be
a pointer that just happened to point inside of that block.
> Any ideas on why it only fails in SLES10-Beta10-ia32? Is it because of
> glibc-2.4?
There are slight differences between glibc allocation/deallocation patterns.
These slight differences often account for leaked/possibly leaked/reachable
differences in running of the same program on different machines.
Try running the test case below (which does exactly the same thing
in all cases) like this:
valgrind ./a.out # definitely lost
valgrind ./a.out 1 # definitely lost
valgrind --freelist-vol=0 ./a.out # reachable
valgrind --freelist-vol=0 ./a.out 1 # possibly lost
and understand the differences.
After that, you'll probably understand the result you got from your
original test.
Cheers,
$ cat plk.c
#include <stdlib.h>
#include <stdio.h>
char *p;
int main(int argc, char *argv[])
{
void *q;
p = malloc(100); free(p);
printf("p = %p\n", p);
if (1 < argc) p += 1;
q = malloc(100);
printf("q = %p\n", q);
return 0;
}
|
|
From: Tao T W. <wan...@cn...> - 2006-04-30 07:41:58
|
Paul Pluzhnikov wrote: > What it means is that there is a reachable pointer (or data that looks like > a pointer) somewhere, which happens to point 'inside' (but not at the > beginning) > of the block. The bigger the block, the more there is a chance that > there will be > a pointer that just happened to point inside of that block. > > > Any ideas on why it only fails in SLES10-Beta10-ia32? Is it because of > > glibc-2.4? > > There are slight differences between glibc allocation/deallocation patterns. > These slight differences often account for leaked/possibly leaked/reachable > differences in running of the same program on different machines. > Thanks! It seems that a bigger malloced block increased the chance of finding a data/pointer somewhere that happens to point inside the not-freed block. I'm just curious where will valgrind search for such kind of pointers? Are there any ways to get rid of those "bogus pointers" to make leak detection more accurate? |
|
From: Bryan M. <om...@br...> - 2006-04-30 14:33:19
|
Tao, you can try my omega tool: http://www.brainmurders.eclipse.co.uk/omega.html It is designed to track only memory leaks. It's still beta so it may work well for you, it may not but either way I would like to hear about your results. I saved your example program as userlist.c, compiled it with gcc -g -o userlist userlist.c and then ran omega on it: $ > valgrind --tool=omega ./userlist ==10544== Omega-beta2, An instant memory leak detector. ==10544== Copyright (C) 2006, and GNU GPL'd, by Bryan Meredith. ==10544== Using LibVEX rev 1419, a library for dynamic binary translation. ==10544== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==10544== Using valgrind-3.2.0.SVN, a dynamic binary instrumentation framework. ==10544== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==10544== For more details, rerun with: -v ==10544== ==10544== ==10544== ==10544== ==10544== Omega Leak Summary ==10544== ================== ==10544== Loss Record 1: Leaked 100000 (0x186A0) bytes in 1 block ==10544== at 0x804839A: main (userlist.c:12) ==10544== Block allocated ==10544== at 0x401AD9E: malloc (vg_replace_malloc.c:149) ==10544== by 0x804838E: main (userlist.c:9) ==10544== ==10544== Loss Record 2: Leaked 100000 (0x186A0) bytes in 1 block ==10544== at 0x804839A: main (userlist.c:12) ==10544== Block allocated ==10544== at 0x401AD9E: malloc (vg_replace_malloc.c:149) ==10544== by 0x804837D: main (userlist.c:8) ==10544== Note that line 12 is where your pointer variables go out of scope. Is that what you were looking for? Hope this helps, Bryan "Brain Murders" Meredith Tao T Wang wrote: > > Paul Pluzhnikov wrote: > > > What it means is that there is a reachable pointer (or data that > looks like > > a pointer) somewhere, which happens to point 'inside' (but not at the > > beginning) > > of the block. The bigger the block, the more there is a chance that > > there will be > > a pointer that just happened to point inside of that block. > > > > > Any ideas on why it only fails in SLES10-Beta10-ia32? Is it because of > > > glibc-2.4? > > > > There are slight differences between glibc allocation/deallocation > patterns. > > These slight differences often account for leaked/possibly > leaked/reachable > > differences in running of the same program on different machines. > > > > Thanks! It seems that a bigger malloced block increased the chance of > finding > a data/pointer somewhere that happens to point inside the not-freed block. > > I'm just curious where will valgrind search for such kind of pointers? > Are there any > ways to get rid of those "bogus pointers" to make leak detection more > accurate? |
|
From: Jim C. <jim...@gm...> - 2006-05-02 12:00:35
|
Paul Pluzhnikov wrote:
> Tao T Wang wrote:
>
>> It's very strange.
>
> Not at all.
>
>> In the source code, ptr1 and ptr2 are exactly the same, but valgrind
>> reported different memory leaks, one is "definitely lost" and the
>> other is "possibly lost"
>
> You don't understand what "possibly lost" means.
> If you did, you would not be surprized.
>
> What it means is that there is a reachable pointer (or data that looks
> like
> a pointer) somewhere, which happens to point 'inside' (but not at the
> beginning)
> of the block. The bigger the block, the more there is a chance that
> there will be
> a pointer that just happened to point inside of that block.
>
>> Any ideas on why it only fails in SLES10-Beta10-ia32? Is it because
>> of glibc-2.4?
>
> There are slight differences between glibc allocation/deallocation
> patterns.
> These slight differences often account for leaked/possibly
> leaked/reachable
> differences in running of the same program on different machines.
>
> Try running the test case below (which does exactly the same thing
> in all cases) like this:
>
> valgrind ./a.out # definitely lost
> valgrind ./a.out 1 # definitely lost
> valgrind --freelist-vol=0 ./a.out # reachable
> valgrind --freelist-vol=0 ./a.out 1 # possibly lost
>
> and understand the differences.
>
> After that, you'll probably understand the result you got from your
> original test.
>
> Cheers,
>
> $ cat plk.c
> #include <stdlib.h>
> #include <stdio.h>
>
> char *p;
> int main(int argc, char *argv[])
> {
> void *q;
> p = malloc(100); free(p);
> printf("p = %p\n", p);
> if (1 < argc) p += 1;
> q = malloc(100);
> printf("q = %p\n", q);
> return 0;
> }
>
Nice Posting !
This question is already addressed in the FAQ,
but youve added a *lot* of clarity to the whys and wherefors.
Esp wrt the same program lines eliciting different errs under
casually similar situations.
Id like to see it added to the FAQ (I went looking for the wiki-edit
button),
and possibly a link to where the manual details it.
Thanks!
|
|
From: Ivan N. <iv...@0x...> - 2006-05-02 20:16:54
|
> > Id like to see it added to the FAQ (I went looking for the wiki-edit > button), > and possibly a link to where the manual details it. > Can we start up a Valgrind Wiki on the main Valgrind page? Ivan |