XelKarin Tux's lil' helper
Joined: 29 Dec 2003 Posts: 85
|
Posted: Sun Jul 21, 2024 7:42 pm Post subject: Running valgrind under qemu-arm chroot |
|
|
I've set up an ARMv7a HardFP chroot for development and was hoping to use valgrind within it, but valgrind fails to run period. The following error is shown if I run it as valgrind --help or even run it with no arguments. I tried exporting the QEMU_RESERVED_VA=4294967296 environment variable, but it didn't have any effect.
Code: | --105:0: aspacem <<< SHOW_SEGMENTS: out_of_memory (35 segments)
--105:0: aspacem 2 segment names in 2 slots
--105:0: aspacem freelist is empty
--105:0: aspacem (0,4,9) /usr/bin/qemu-arm
--105:0: aspacem (1,26,3) /usr/libexec/valgrind/memcheck-arm-linux
--105:0: aspacem 0: RSVN 0000000000-00003fffff 4194304 ----- SmFixed
--105:0: aspacem 1: FILE 0000400000-0000400fff 4096 r---- d=0x804 i=92816566 o=0 (0,4)
--105:0: aspacem 2: FILE 0000401000-00006b3fff 2830336 r-x-- d=0x804 i=92816566 o=4096 (0,4)
--105:0: aspacem 3: FILE 00006b4000-00007fcfff 1347584 r---- d=0x804 i=92816566 o=2834432 (0,4)
--105:0: aspacem 4: FILE 00007fd000-0000801fff 20480 r---- d=0x804 i=92816566 o=4177920 (0,4)
--105:0: aspacem 5: FILE 0000802000-0000839fff 229376 rw--- d=0x804 i=92816566 o=4198400 (0,4)
--105:0: aspacem 6: ANON 000083a000-000084bfff 73728 rw---
--105:0: aspacem 7: RSVN 000084c000-0000fc0fff 7819264 ----- SmFixed
--105:0: aspacem 8: ANON 0000fc1000-000104ffff 585728 rw---
--105:0: aspacem 9: RSVN 0001050000-000201bfff 15m ----- SmFixed
--105:0: aspacem 10: ANON 000201c000-000201cfff 4096 r----
--105:0: aspacem 11: ANON 000201d000-004202cfff 1024m -----
--105:0: aspacem 12: ANON 004202d000-004282cfff 8388608 rw---
--105:0: aspacem 13: ANON 004282d000-004282dfff 4096 r----
--105:0: aspacem 14: ANON 004282e000-005a02bfff 375m -----
--105:0: aspacem 15: FILE 005a02c000-005a280fff 2445312 r---- d=0x804 i=93719851 o=0 (1,26)
--105:0: aspacem 16: FILE 005a281000-005a284fff 16384 rw--- d=0x804 i=93719851 o=2441216 (1,26)
--105:0: aspacem 17: ANON 005a285000-005abf4fff 9895936 rw---
--105:0: aspacem 18: RSVN 005abf5000-00afffffff 1364m ----- SmFixed
--105:0: aspacem 19: ANON 00b0000000-00b6417fff 100m rwx--
--105:0: aspacem 20: ANON 00b6418000-00b6438fff 135168 rw---
--105:0: aspacem 21: ANON 00b6439000-00b654dfff 1134592 rwx--
--105:0: aspacem 22: ANON 00b654e000-00b6551fff 16384 r----
--105:0: aspacem 23: ANON 00b6552000-00b6553fff 8192 r-x--
--105:0: aspacem 24: ANON 00b6554000-00b7ffefff 26m rwx--
--105:0: aspacem 25: ANON 00b7fff000-00b7ffffff 4096 -----
--105:0: aspacem 26: ANON 00b8000000-00b8020fff 135168 rw---
--105:0: aspacem 27: ANON 00b8021000-00bbffffff 63m -----
--105:0: aspacem 28: RSVN 00bc000000-00bd781fff 23m ----- SmFixed
--105:0: aspacem 29: ANON 00bd782000-00bd802fff 528384 rw---
--105:0: aspacem 30: ANON 00bd803000-00bd803fff 4096 -----
--105:0: aspacem 31: ANON 00bd804000-00be003fff 8388608 rw---
--105:0: aspacem 32: RSVN 00be004000-00fffeffff 1055m ----- SmFixed
--105:0: aspacem 33: anon 00ffff0000-00ffff0fff 4096 r-x--
--105:0: aspacem 34: RSVN 00ffff1000-00ffffffff 61440 ----- SmFixed
--105:0: aspacem >>>
--105-- core : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 4 rzB
--105-- dinfo : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 4 rzB
--105-- (null) : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 0 rzB
--105-- demangle: 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 4 rzB
--105-- ttaux : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 4 rzB
--105-- translate: 0 guest insns, 0 traces, 0 uncond chased, 0 cond chased
--105-- translate: no SP updates identified
--105-- translate: PX: SPonly 0, UnwRegs 0, AllRegs 0, AllRegsAllInsns 0
--105-- tt/tc: 0 tt lookups requiring 0 probes
--105-- tt/tc: 0 fast-cache updates, 0 flushes
--105-- transtab: new 0 (0 -> 0; ratio 0.0) [0 scs] avg tce size 0
--105-- transtab: dumped 0 (0 -> ??) (sectors recycled 0)
--105-- transtab: discarded 0 (0 -> ??)
--105-- scheduler: 0 event checks.
--105-- scheduler: 0 indir transfers, 0 misses (1 in 0) ..
--105-- scheduler: .. of which: 0 hit0, 0 hit1, 0 hit2, 0 hit3, 0 missed
--105-- scheduler: 0/0 major/minor sched events.
--105-- sanity: 0 cheap, 0 expensive checks.
==105==
==105== Valgrind's memory management: out of memory: Invalid argument
==105== newSuperblock's request for 4194304 bytes failed.
==105== 1,697,267,712 bytes have already been mmap-ed ANONYMOUS.
==105== Valgrind cannot continue. Sorry.
==105==
==105== There are several possible reasons for this.
==105== - You have some kind of memory limit in place. Look at the
==105== output of 'ulimit -a'. Is there a limit on the size of
==105== virtual memory or address space?
==105== - You have run out of swap space.
==105== - You have some policy enabled that denies memory to be
==105== executable (for example selinux deny_execmem) that causes
==105== mmap to fail with Permission denied.
==105== - Valgrind has a bug. If you think this is the case or you are
==105== not sure, please let us know and we'll try to fix it.
==105== Please note that programs can take substantially more memory than
==105== normal when running under Valgrind tools, eg. up to twice or
==105== more, depending on the tool. On a 64-bit machine, Valgrind
==105== should be able to make use of up 32GB memory. On a 32-bit
==105== machine, Valgrind should be able to use all the memory available
==105== to a single process, up to 4GB if that's how you have your
==105== kernel configured. Most 32-bit Linux setups allow a maximum of
==105== 3GB per process.
==105==
==105== Whatever the reason, Valgrind cannot continue. Sorry. |
|
|