|
From: Russ F. <rus...@ho...> - 2003-10-10 14:47:59
|
I'm a semi-newbie to valgrind, and a positive newbie to the application I'm debugging. I'm getting a message from Valgrind that I don't understand; can you help me? I'm running with --leak-check=yes, --show-reachable=yes. Valgrind is saying: ==5843== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==5843== malloc/free: in use at exit: 3036062 bytes in 3230 blocks. ==5843== malloc/free: 24202 allocs, 20972 frees, 9377725 bytes allocated. ==5843== For counts of detected errors, rerun with: -v ==5843== searching for pointers to 3230 not-freed blocks. ==5843== checked 6748468 bytes. ==5843== ==5843== 0 bytes in 383 blocks are definitely lost in loss record 1 of 9 ==5843== at 0x4002B905: malloc (vg_replace_malloc.c:153) ==5843== by 0x80507F8: ... What does it mean, "0 bytes in 383 blocks are definitely lost?" Semantically, if I lose zero bytes, then I'm not leaking. I don't believe my logic, though - I believe a leak is taking place, but for some reason, Valgrind is unable to quantify the amount being leaked. Has this been seen before? If so, what does it mean, and what more should I do to my application to get clearer results? Thanks, Russ Fink _________________________________________________________________ Express yourself with MSN Messenger 6.0 -- download now! http://www.msnmessenger-download.com/tracking/reach_general |
|
From: Peyush K. <pey...@ho...> - 2010-07-30 12:50:13
|
Hi all, Can anybody suggest on below error "0 bytes in 1 blocks are definitely lost in loss record 1 of 7,541" Whad does error mean Is there a leak.. ?for how many bytes or it indicates some valgrind problem can we overcome this by some ocnfiguration I get this error when I kill process using Ctrl-C Thanks &Regards, Peyush. |
|
From: Nicholas N. <nj...@ca...> - 2003-10-10 15:00:20
|
On Fri, 10 Oct 2003, Russ Fink wrote: > I'm a semi-newbie to valgrind, and a positive newbie to the application I'm > debugging. I'm getting a message from Valgrind that I don't understand; can > you help me? > > I'm running with --leak-check=yes, --show-reachable=yes. Valgrind is > saying: > > ==5843== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ==5843== malloc/free: in use at exit: 3036062 bytes in 3230 blocks. > ==5843== malloc/free: 24202 allocs, 20972 frees, 9377725 bytes allocated. > ==5843== For counts of detected errors, rerun with: -v > ==5843== searching for pointers to 3230 not-freed blocks. > ==5843== checked 6748468 bytes. > ==5843== > ==5843== 0 bytes in 383 blocks are definitely lost in loss record 1 of 9 > ==5843== at 0x4002B905: malloc (vg_replace_malloc.c:153) > ==5843== by 0x80507F8: ... > > What does it mean, "0 bytes in 383 blocks are definitely lost?" > Semantically, if I lose zero bytes, then I'm not leaking. I don't believe > my logic, though - I believe a leak is taking place, but for some reason, > Valgrind is unable to quantify the amount being leaked. Could you be leaking zero-sized heap blocks? If you do leak a zero-sized block, you really are losing memory because every heap block has administration bytes at the start and end. N |
|
From: Olly B. <ol...@su...> - 2003-10-10 15:17:12
|
On Fri, Oct 10, 2003 at 04:00:17PM +0100, Nicholas Nethercote wrote:
> Could you be leaking zero-sized heap blocks? If you do leak a zero-sized
> block, you really are losing memory because every heap block has
> administration bytes at the start and end.
It occurs to me that VALGRIND_COUNT_LEAKS has a flaw, as it tells you
how many bytes were leaked, not how many blocks. So it'll effectively
ignore leaks of zero-sized blocks...
Cheers,
Olly
|
|
From: Joshua Moore-O. <jo...@ch...> - 2003-10-10 15:02:52
|
I think the source of your problems comes from this bit <snip> > ==5843== malloc/free: 24202 allocs, 20972 frees, 9377725 bytes allocated. </snip> try fixing that up first and I think the second error should go away :). You have more frees than allocs. Josh. |
|
From: Derick R. <d.r...@jd...> - 2003-10-10 15:08:32
|
On Fri, 10 Oct 2003, Joshua Moore-Oliva wrote: > I think the source of your problems comes from this bit > > <snip> > > ==5843== malloc/free: 24202 allocs, 20972 frees, 9377725 bytes allocated. > </snip> > > try fixing that up first and I think the second error should go away :). You > have more frees than allocs. 24202 - 20972 is still greater than 0 for me ;-) Derick -- ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ International PHP Magazine http://www.php-mag.net/ ------------------------------------------------------------------------- |
|
From: Lee K. <lki...@cs...> - 2003-10-10 15:10:19
|
Russ Fink writes:
> Semantically, if I lose zero bytes, then I'm not leaking. I don't believe
> my logic, though - I believe a leak is taking place, but for some reason,
> Valgrind is unable to quantify the amount being leaked.
Because it's perfectly valid (if non-portable) to allocate memory of a
size 0 bytes! Such an allocation still consumes system resources
(i.e. the list of memory blocks alloacted). Consider the program:
#include <stdlib.h>
#include <stdio.h>
void main(void)
{
void *ptr = malloc(0);
printf("%p\n", ptr);
}
And the Valgrind run:
==11300== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==11300== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==11300== Using valgrind-20030725, a program supervision framework for x86-linux.
==11300== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==11300== Estimated CPU clock rate is 1911 MHz
==11300== For more details, rerun with: -v
==11300==
0x411ba024
==11300==
==11300== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==11300== malloc/free: in use at exit: 0 bytes in 1 blocks.
==11300== malloc/free: 1 allocs, 0 frees, 0 bytes allocated.
==11300== For counts of detected errors, rerun with: -v
==11300== searching for pointers to 1 not-freed blocks.
==11300== checked 3635076 bytes.
==11300==
==11300== 0 bytes in 1 blocks are definitely lost in loss record 1 of 1
==11300== at 0x4002942A: malloc (vg_replace_malloc.c:153)
==11300== by 0x8048375: main (test.c:6)
==11300== by 0x40257A46: __libc_start_main (in /lib/libc-2.3.2.so)
==11300== by 0x80482CC: ??? (start.S:81)
==11300==
==11300== LEAK SUMMARY:
==11300== definitely lost: 0 bytes in 1 blocks.
==11300== possibly lost: 0 bytes in 0 blocks.
==11300== still reachable: 0 bytes in 0 blocks.
==11300== suppressed: 0 bytes in 0 blocks.
==11300== Reachable blocks (those to which a pointer was found) are not shown.
==11300== To see them, rerun with: --show-reachable=yes
==11300==
Does this clear things up?
L.
|