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.