Re: Valgrind on ARM64, KVM
On a Pi 3B with Raspbian Jessie I get:
==2188== Memcheck, a memory error detector
==2188== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==2188== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==2188== Command: ls
==2188==
getline.txt
InRelease
inrelease.txt
rsp.txt
valgrindls.txt
==2188==
==2188== HEAP SUMMARY:
==2188== in use at exit: 13,815 bytes in 9 blocks
==2188== total heap usage: 43 allocs, 34 frees, 49,009 bytes allocated
==2188==
==2188== LEAK SUMMARY:
==2188== definitely lost: 0 bytes in 0 blocks
==2188== indirectly lost: 0 bytes in 0 blocks
==2188== possibly lost: 0 bytes in 0 blocks
==2188== still reachable: 13,815 bytes in 9 blocks
==2188== suppressed: 0 bytes in 0 blocks
==2188== Rerun with --leak-check=full to see details of leaked memory
==2188==
==2188== For counts of detected and suppressed errors, rerun with: -v
==2188== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
So it does work sometimes. I've also had trouble with it.
On 9/22/17, Phil Endecott <spam_from_debian_arm@chezphil.org> wrote:
> Hi everyone,
>
> I'm getting mixed results trying to use valgrind on various ARM64
> devices. Specifically, it works on my ODROID-C2 (Amlogic SoC with
> kernel 3.14.29), and on my APM Xgene system with kernel 4.9.1801,
> but not on a Scaleway virtual machine (Cavium ThunderX with kernel
> 4.9.23, under KVM) [*]. They are all running stretch and valgrind
> 3.12.0.SVN.
>
> Google reports various issues using KVM/QEMU with valgrind but
> I think that's mostly related to running valgrind on the KVM
> host, not the guest. Or something.
>
> It would be useful to know whether this works for other people -
> especially if anyone is using KVM on ARM64 on another platform.
> If a few readers would be kind enough to:
>
> # apt-get install valgrind
> $ valgrind ls
>
> and report what happens, that would be wonderful.
>
> [*] The failure mode I see is that it runs forever at 100% CPU.
> If I strace the valgrind process - which may or may not be a
> sensible thing to do - I see this constantly repeated:
>
> rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
> rt_sigtimedwait(~[], 0x802e9be28, {tv_sec=0, tv_nsec=0}, 8) = -1 EAGAIN
> (Resource temporarily unavailable)
> rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) =
> 0
> gettid() = 20487
> gettid() = 20487
> write(1029, "P", 1) = 1
> gettid() = 20487
> read(1028, "P", 1) = 1
> gettid() = 20487
>
>
>
> Thanks, Phil.
>
>
>
--
-------------
No, I won't call it "climate change", do you have a "reality problem"? - AB1JX
Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Reply to: