Opt: --show-reachable=yes
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
|
|
|
Re: Opt: --show-reachable=yes
by Dan Kegel-2
::
Rate this Message:
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) ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Valgrind-users mailing list Valgrind-users@... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
|
|
|
|
Re: Opt: --show-reachable=yes
by Bugzilla from philippe.waroquiers@eurocontrol.int
::
Rate this Message:
>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. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Valgrind-users mailing list Valgrind-users@... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
|
Re: Opt: --show-reachable=yes
by Dan Kegel-2
::
Rate this Message:
<philippe.waroquiers@...> 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 ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Valgrind-users mailing list Valgrind-users@... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
|
Re: Opt: --show-reachable=yes
by Bugzilla from philippe.waroquiers@eurocontrol.int
::
Rate this Message:
>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. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Valgrind-users mailing list Valgrind-users@... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
|
Re: Opt: --show-reachable=yes
by Dan Kegel-2
::
Rate this Message:
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. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Valgrind-users mailing list Valgrind-users@... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
| Free embeddable forum powered by Nabble | Forum Help |
