|
From: Alberto A. <al...@gg...> - 2004-04-28 05:18:29
|
I have a simple test case to see how memory allocated is
reported upon an unplanned exit. Here is the code:
int main() {
char *ptr;
ptr = (char *)malloc(200);
return 0;
}
Upon running valgrind 2.1.1 and 2.0.0 I get the following:
valgrind --tool=memcheck --leak-check=yes ./test-memlost-valgrind
==20925== Memcheck, a memory error detector for x86-linux.
==20925== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
==20925== Using valgrind-2.1.1, a program supervision framework for
x86-linux.
==20925== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==20925== For more details, rerun with: -v
==20925==
==20925==
==20925== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from
1)
==20925== malloc/free: in use at exit: 200 bytes in 1 blocks.
==20925== malloc/free: 1 allocs, 0 frees, 200 bytes allocated.
==20925== For counts of detected errors, rerun with: -v
==20925== searching for pointers to 1 not-freed blocks.
==20925== checked 1423392 bytes.
==20925==
==20925== 200 bytes in 1 blocks are definitely lost in loss record 1 of
1
==20925== at 0x3C01E274: malloc (vg_replace_malloc.c:105)
==20925== by 0x8048364: main (in
/ggs/corp/software/ggsyslib/testsuite/test-memlost-valgrind)
==20925==
==20925== LEAK SUMMARY:
==20925== definitely lost: 200 bytes in 1 blocks.
==20925== possibly lost: 0 bytes in 0 blocks.
==20925== still reachable: 0 bytes in 0 blocks.
==20925== suppressed: 0 bytes in 0 blocks.
==20925== Reachable blocks (those to which a pointer was found) are not
shown.
==20925== To see them, rerun with: --show-reachable=yes
Shouldn't this be reported as "still reachable?" Does this have
anything to do with FAQ 5.2?
Thanks,
Alberto
--
Alberto Alonso Global Gate Systems LLC.
(512) 260-2523 http://www.ggsys.net
Hardware, consulting, collocation, monitoring and remote backups
|
|
From: David E. <tw...@us...> - 2004-04-28 05:44:00
|
On Wed, 2004-04-28 at 07:18, Alberto Alonso wrote:
> I have a simple test case to see how memory allocated is
> reported upon an unplanned exit. Here is the code:
>
> int main() {
> char *ptr;
> ptr = (char *)malloc(200);
> return 0;
> }
>
> Upon running valgrind 2.1.1 and 2.0.0 I get the following:
>
>
> valgrind --tool=memcheck --leak-check=yes ./test-memlost-valgrind
> ==20925== Memcheck, a memory error detector for x86-linux.
> ==20925== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
> ==20925== Using valgrind-2.1.1, a program supervision framework for
> x86-linux.
> ==20925== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
> ==20925== For more details, rerun with: -v
> ==20925==
> ==20925==
> ==20925== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from
> 1)
> ==20925== malloc/free: in use at exit: 200 bytes in 1 blocks.
> ==20925== malloc/free: 1 allocs, 0 frees, 200 bytes allocated.
> ==20925== For counts of detected errors, rerun with: -v
> ==20925== searching for pointers to 1 not-freed blocks.
> ==20925== checked 1423392 bytes.
> ==20925==
> ==20925== 200 bytes in 1 blocks are definitely lost in loss record 1 of
> 1
> ==20925== at 0x3C01E274: malloc (vg_replace_malloc.c:105)
> ==20925== by 0x8048364: main (in
> /ggs/corp/software/ggsyslib/testsuite/test-memlost-valgrind)
> ==20925==
> ==20925== LEAK SUMMARY:
> ==20925== definitely lost: 200 bytes in 1 blocks.
> ==20925== possibly lost: 0 bytes in 0 blocks.
> ==20925== still reachable: 0 bytes in 0 blocks.
> ==20925== suppressed: 0 bytes in 0 blocks.
> ==20925== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==20925== To see them, rerun with: --show-reachable=yes
>
>
> Shouldn't this be reported as "still reachable?" Does this have
> anything to do with FAQ 5.2?
If ptr was a global variable it would be "still reachable".
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
ScummVM - http://scummvm.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: Alberto A. <al...@gg...> - 2004-04-28 05:52:04
|
So basically, as I suspected from FAQ 5.2 if the pointer
is in the stack valgrind won't find it as a reference to
the allocated memory.
Is that correct?
Thanks,
Alberto
On Wed, 2004-04-28 at 00:43, David Eriksson wrote:
> On Wed, 2004-04-28 at 07:18, Alberto Alonso wrote:
> > I have a simple test case to see how memory allocated is
> > reported upon an unplanned exit. Here is the code:
> >
> > int main() {
> > char *ptr;
> > ptr = (char *)malloc(200);
> > return 0;
> > }
> >
> > Upon running valgrind 2.1.1 and 2.0.0 I get the following:
> >
> >
> > valgrind --tool=memcheck --leak-check=yes ./test-memlost-valgrind
> > ==20925== Memcheck, a memory error detector for x86-linux.
> > ==20925== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward.
> > ==20925== Using valgrind-2.1.1, a program supervision framework for
> > x86-linux.
> > ==20925== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
> > ==20925== For more details, rerun with: -v
> > ==20925==
> > ==20925==
> > ==20925== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from
> > 1)
> > ==20925== malloc/free: in use at exit: 200 bytes in 1 blocks.
> > ==20925== malloc/free: 1 allocs, 0 frees, 200 bytes allocated.
> > ==20925== For counts of detected errors, rerun with: -v
> > ==20925== searching for pointers to 1 not-freed blocks.
> > ==20925== checked 1423392 bytes.
> > ==20925==
> > ==20925== 200 bytes in 1 blocks are definitely lost in loss record 1 of
> > 1
> > ==20925== at 0x3C01E274: malloc (vg_replace_malloc.c:105)
> > ==20925== by 0x8048364: main (in
> > /ggs/corp/software/ggsyslib/testsuite/test-memlost-valgrind)
> > ==20925==
> > ==20925== LEAK SUMMARY:
> > ==20925== definitely lost: 200 bytes in 1 blocks.
> > ==20925== possibly lost: 0 bytes in 0 blocks.
> > ==20925== still reachable: 0 bytes in 0 blocks.
> > ==20925== suppressed: 0 bytes in 0 blocks.
> > ==20925== Reachable blocks (those to which a pointer was found) are not
> > shown.
> > ==20925== To see them, rerun with: --show-reachable=yes
> >
> >
> > Shouldn't this be reported as "still reachable?" Does this have
> > anything to do with FAQ 5.2?
>
> If ptr was a global variable it would be "still reachable".
--
Alberto Alonso Global Gate Systems LLC.
(512) 260-2523 http://www.ggsys.net
Hardware, consulting, collocation, monitoring and remote backups
|
|
From: Alberto A. <al...@gg...> - 2004-04-28 06:18:21
|
Ahhh, that makes too much sense :-) If instead of a return I do an exit then the stack still has ptr, and then valgrind reports it as reachable Thanks for clearing things up. Alberto On Wed, 2004-04-28 at 01:06, Michael Smith wrote: > On Wednesday 28 April 2004 15:52, Alberto Alonso wrote: > > So basically, as I suspected from FAQ 5.2 if the pointer > > is in the stack valgrind won't find it as a reference to > > the allocated memory. > > > > Is that correct? > > > > At exit, ptr is no longer _on_ the stack, since main() has returned (it's > possibly still in memory just off the top of the stack, unless something else > has overwritten it, but that's irrelevant - logically, it's just not there > any more). valgrind won't look for it there. > > This isn't related to FAQ/5.2. > > Mike -- Alberto Alonso Global Gate Systems LLC. (512) 260-2523 http://www.ggsys.net Hardware, consulting, collocation, monitoring and remote backups |