Hi!
I'm trying to use valgrind on an a15, 32 hf environment obviously.
I have -g on with no optimization for all my code that is being run.
Command line options for valgrind are:
valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --leak-resolution=high --track-origins=yes --num-callers=10 ./matvec
I've tried num-callers as high as 50 it makes no difference. I get almost zero information when it comes to leaks and the call stack. Ok great it's nice to see things broken down between malloc and new and so on. But without a call stack this is pretty worthless.
snippet:
==19013== 1,937,944 bytes in 18,389 blocks are still reachable in loss record 8 of 9 ==19013== at 0x482DE80: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so) ==19013== ==19013== 4,524,046 bytes in 14,368 blocks are still reachable in loss record 9 of 9 ==19013== at 0x482E420: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so) ==19013== ==19013== LEAK SUMMARY: ==19013== definitely lost: 328 bytes in 6 blocks ==19013== indirectly lost: 396 bytes in 3 blocks ==19013== possibly lost: 808 bytes in 26 blocks ==19013== still reachable: 8,342,474 bytes in 37,405 blocks ==19013== suppressed: 0 bytes in 0 blocks
Did I miss an option? or something obvious which would output more information ?
Thanks!
On Fri, 13 Jun 2014 10:14:37 -0700 Tom Gall tom.gall@linaro.org wrote:
Hi!
I'm trying to use valgrind on an a15, 32 hf environment obviously.
I have -g on with no optimization for all my code that is being run.
Command line options for valgrind are:
valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --leak-resolution=high --track-origins=yes --num-callers=10 ./matvec
I've tried num-callers as high as 50 it makes no difference. I get almost zero information when it comes to leaks and the call stack. Ok great it's nice to see things broken down between malloc and new and so on. But without a call stack this is pretty worthless.
snippet:
==19013== 1,937,944 bytes in 18,389 blocks are still reachable in loss record 8 of 9 ==19013== at 0x482DE80: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so) ==19013== ==19013== 4,524,046 bytes in 14,368 blocks are still reachable in loss record 9 of 9 ==19013== at 0x482E420: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so) ==19013== ==19013== LEAK SUMMARY: ==19013== definitely lost: 328 bytes in 6 blocks ==19013== indirectly lost: 396 bytes in 3 blocks ==19013== possibly lost: 808 bytes in 26 blocks ==19013== still reachable: 8,342,474 bytes in 37,405 blocks ==19013== suppressed: 0 bytes in 0 blocks
Did I miss an option? or something obvious which would output more information ?
The Gentoo ebuild says:
pkg_postinst() { elog "Valgrind will not work if glibc does not have debug symbols." elog "To fix this you can add splitdebug to FEATURES in make.conf" elog "and remerge glibc. See:" elog "https://bugs.gentoo.org/show_bug.cgi?id=214065" elog "https://bugs.gentoo.org/show_bug.cgi?id=274771" elog "https://bugs.gentoo.org/show_bug.cgi?id=388703" }
And Vagrind has been working fine in Gentoo on ARM.
On 13 June 2014 18:14, Tom Gall tom.gall@linaro.org wrote:
Hi Tom,
I'm trying to use valgrind on an a15, 32 hf environment obviously.
I have -g on with no optimization for all my code that is being run.
Command line options for valgrind are:
valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --leak-resolution=high --track-origins=yes --num-callers=10 ./matvec
I tried this command line on Ubuntu Trusty and got complete looking call stacks.
I'm on 12.04 precise.
Bummer.
On Tue, Jun 17, 2014 at 2:35 AM, Will Newton will.newton@linaro.org wrote:
On 13 June 2014 18:14, Tom Gall tom.gall@linaro.org wrote:
Hi Tom,
I'm trying to use valgrind on an a15, 32 hf environment obviously.
I have -g on with no optimization for all my code that is being run.
Command line options for valgrind are:
valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --leak-resolution=high --track-origins=yes --num-callers=10 ./matvec
I tried this command line on Ubuntu Trusty and got complete looking call stacks.
-- Will Newton Toolchain Working Group, Linaro
On Tue, 17 Jun 2014 08:17:26 -0500 Tom Gall tom.gall@linaro.org wrote:
On Tue, Jun 17, 2014 at 2:35 AM, Will Newton will.newton@linaro.org wrote:
On 13 June 2014 18:14, Tom Gall tom.gall@linaro.org wrote:
Hi Tom,
I'm trying to use valgrind on an a15, 32 hf environment obviously.
I have -g on with no optimization for all my code that is being run.
Command line options for valgrind are:
valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --leak-resolution=high --track-origins=yes --num-callers=10 ./matvec
I tried this command line on Ubuntu Trusty and got complete looking call stacks.
I'm on 12.04 precise.
Bummer.
Do you have something like libc-dbg installed in your system? Having the glibc debugging symbols is important.
Yes I do. I think this might be a debug-file-directory setting issue. The app and one of the libs it's using are in /usr/local/ the debug for libc is in /usr/. Not sure you can have multiple directories in .gdbinit for debug-file-directory. Least it seems to be ignoring it.
Figure I'll trying copying the debug libs all over into one place and see what that does. Failing that. Upgrade time.
On Tue, Jun 17, 2014 at 8:33 AM, Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Tue, 17 Jun 2014 08:17:26 -0500 Tom Gall tom.gall@linaro.org wrote:
On Tue, Jun 17, 2014 at 2:35 AM, Will Newton will.newton@linaro.org wrote:
On 13 June 2014 18:14, Tom Gall tom.gall@linaro.org wrote:
Hi Tom,
I'm trying to use valgrind on an a15, 32 hf environment obviously.
I have -g on with no optimization for all my code that is being run.
Command line options for valgrind are:
valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --leak-resolution=high --track-origins=yes --num-callers=10 ./matvec
I tried this command line on Ubuntu Trusty and got complete looking call stacks.
I'm on 12.04 precise.
Bummer.
Do you have something like libc-dbg installed in your system? Having the glibc debugging symbols is important.
-- Best regards, Siarhei Siamashka
-
Siarhei Siamashka -
Tom Gall -
Will Newton