|
From: Israel L. A. <isr...@po...> - 2009-09-23 17:19:29
|
Israel Lins Albuquerque escreveu:
> I can't understand how this work somebody can help me?
> Show me a example!
>
> Regards,
>
>
I understand now see the exemple:
But I fink that option does not make sense to be configurated, this can
always on!!!
#include <stdlib.h>
#include <stdio.h>
int* g = NULL;
int main() {
int* x = (int*)malloc(sizeof(int) * 100); // un-reachable
g = (int*)malloc(sizeof(int) * 100); // un-reachable
g = (int*)malloc(sizeof(int) * 100); // reachable
return 0;
}
--
Israel Lins Albuquerque
Desenvolvimento
Polibrás Brasil Software Ltda.
|
|
From: Dan K. <da...@ke...> - 2009-09-23 18:00:09
|
On Wed, Sep 23, 2009 at 10:43 AM, Israel Lins Albuquerque <isr...@po...> wrote: > That's works fine for me too, but I can't see the purpose for this... > I can't see benefices to this option don't stay always on! I need it off, and in fact I turn even more off, see https://bugs.kde.org/show_bug.cgi?id=201170 I build with that patch and use --show-possible=no to avoid generating gigabytes of warnings of questionable utility. So, the short answer is: big apps that are trying to stamp out all their memory leaks often need to focus just on the smallest set of highest value memory leak errors to keep from drowning. |
|
From: WAROQUIERS P. <phi...@eu...> - 2009-09-24 09:08:01
|
>I need it off, and in fact I turn even more off, see >https://bugs.kde.org/show_bug.cgi?id=201170 >I build with that patch and use --show-possible=no to avoid >generating gigabytes of warnings of questionable utility. > >So, the short answer is: big apps that are trying to >stamp out all their memory leaks often need to focus >just on the smallest set of highest value memory leak >errors to keep from drowning. Effectively, for big aps, show-reachable=no (and a show-possible=no) are helping to focus. For big apps, something which I have found very valuable is "delta leak search" cfr http://bugs.kde.org/show_bug.cgi?id=206802 providing a patch to show only new leak (or new memory allocated). This allows to run the tests, with valgrind requests focussing on leaks (or memory allocation) in specific parts of the application. I see there was at least another request for the same functionality e.g. http://bugs.kde.org/show_bug.cgi?id=81079 ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Dan K. <da...@ke...> - 2009-09-24 10:29:07
|
<phi...@eu...> wrote: > Effectively, for big aps, show-reachable=no (and a show-possible=no) > are helping to focus. > For big apps, something which I have found very valuable is > "delta leak search" > cfr http://bugs.kde.org/show_bug.cgi?id=206802, > ... http://bugs.kde.org/show_bug.cgi?id=81079 I can see where that might be useful. We approximate that by suppressing the leaks we don't care about; having a single client request to say "suppress all leaks seen up to this point" could be handy if you don't have the time to keep a suppression list up to date, e.g. when working on a large app which doesn't normally use valgrind as part of its daily test. - Dan |
|
From: WAROQUIERS P. <phi...@eu...> - 2009-09-24 10:52:39
|
>I can see where that might be useful. We approximate >that by suppressing the leaks we don't care about; >having a single client request to say "suppress >all leaks seen up to this point" could be handy >if you don't have the time to keep a suppression >list up to date, e.g. when working on a large app >which doesn't normally use valgrind as part of its daily test. An other usage pattern for this (which is the one for which we want this wish :) is to start a big application, and then run various tests on this started application (without restarting it each time, as this takes a lot of time in particular with valgrind). Then between each test, we report the leaks (and/or the additional memory allocated). This allows to make a direct link between a functional test (or part of a test) and a leak (or memory allocated). Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Dan K. <da...@ke...> - 2009-09-24 10:58:19
|
We restart our big application for each test, so we don't need that feature to narrow down warnings to particular tests. That said, we're not currently logging the test name with each error (example output: http://build.chromium.org/buildbot/waterfall/builders/Linux%20Tests%20(valgrind)(2)/builds/160/steps/valgrind%20test:%20ui/logs/stdio ) but that's on my to-do list. |
|
From: Dan K. <da...@ke...> - 2009-09-23 17:30:47
|
works for me. Maybe you need to give --leak-check=full?
$ valgrind --leak-check=full ./a.out
Memcheck, a memory error detector
Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
Command: ./a.out
HEAP SUMMARY:
in use at exit: 1,200 bytes in 3 blocks
total heap usage: 3 allocs, 0 frees, 1,200 bytes allocated
400 bytes in 1 blocks are definitely lost in loss record 2 of 3
at 0x4C246F5: malloc
/tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:195
by 0x4004A9: main
/data/dkegel/chrome-build/src/tools/valgrind/memcheck/bad.c:7
400 bytes in 1 blocks are definitely lost in loss record 3 of 3
at 0x4C246F5: malloc
/tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:195
by 0x4004B7: main
/data/dkegel/chrome-build/src/tools/valgrind/memcheck/bad.c:9
LEAK SUMMARY:
definitely lost: 800 bytes in 2 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 400 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-reachable=yes
For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 5 from 0)
$ valgrind --leak-check=full --show-reachable=yes ./a.out
Memcheck, a memory error detector
Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
Command: ./a.out
HEAP SUMMARY:
in use at exit: 1,200 bytes in 3 blocks
total heap usage: 3 allocs, 0 frees, 1,200 bytes allocated
400 bytes in 1 blocks are still reachable in loss record 1 of 3
at 0x4C246F5: malloc
/tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:195
by 0x4004C8: main
/data/dkegel/chrome-build/src/tools/valgrind/memcheck/bad.c:10
400 bytes in 1 blocks are definitely lost in loss record 2 of 3
at 0x4C246F5: malloc
/tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:195
by 0x4004A9: main
/data/dkegel/chrome-build/src/tools/valgrind/memcheck/bad.c:7
400 bytes in 1 blocks are definitely lost in loss record 3 of 3
at 0x4C246F5: malloc
/tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:195
by 0x4004B7: main
/data/dkegel/chrome-build/src/tools/valgrind/memcheck/bad.c:9
LEAK SUMMARY:
definitely lost: 800 bytes in 2 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 400 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 5 from 0)
|