Menu
▾
▴
Re: [Valgrind-developers] Why valgrind could not be used on cavium octeon3?
|
From: zboom <net...@fo...> - 2017-03-30 09:01:35
|
Here is the message printed by the non superuser: root@xxx:~# adduser test Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully root@xxx:~# su test test@xxx:~$ strace -e trace=memory valgrind brk(NULL) = 0x12b160000 mmap(NULL, 9594, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffe80d0000 mmap(NULL, 1790224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffe7f10000 mmap(0xffe80a0000, 196608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x180000) = 0xffe80a0000 mprotect(0xffe80a0000, 65536, PROT_READ) = 0 munmap(0xffe80d0000, 9594) = 0 brk(NULL) = 0x12b160000 brk(0x12b190000) = 0x12b190000 mmap(0x802001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EINVAL (Invalid argument) --4198:0: aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments) --4198:0: aspacem 1 segment names in 1 slots --4198:0: aspacem freelist is empty --4198:0: aspacem (0,4,2) /usr/lib/valgrind/memcheck-mips64-linux --4198:0: aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --4198:0: aspacem 1: 0004000000-0037ffffff 832m --4198:0: aspacem 2: FILE 0038000000-003823ffff 2359296 r-x-- d=0xb301 i=12614 o=0 (0,4) --4198:0: aspacem 3: FILE 0038240000-003826ffff 196608 rw--- d=0xb301 i=12614 o=2293760 (0,4) --4198:0: aspacem 4: ANON 0038270000-003943ffff 17m rwx-- --4198:0: aspacem 5: 0039440000-0801ffffff 31883m --4198:0: aspacem 6: RSVN 0802000000-0802000fff 4096 ----- SmFixed --4198:0: aspacem 7: 0802001000-0fffffffff 32735m --4198:0: aspacem 8: RSVN 1000000000-ffdf95ffff 982521m ----- SmFixed --4198:0: aspacem 9: ANON ffdf960000-ffdf98ffff 196608 rwx-- --4198:0: aspacem 10: RSVN ffdf990000-fffffeffff 518m ----- SmFixed --4198:0: aspacem 11: ANON ffffff0000-ffffffffff 65536 r-x-- --4198:0: aspacem 12: RSVN 10000000000-ffffffffffffffff 16383e ----- SmFixed --4198:0: aspacem >>> --4198-- 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 8 rzB --4198-- 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 8 rzB --4198-- (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 --4198-- 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 8 rzB --4198-- 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 8 rzB --4198-- translate: no SP updates identified --4198-- translate: PX: SPonly 0, UnwRegs 0, AllRegs 0, AllRegsAllInsns 0 --4198-- tt/tc: 0 tt lookups requiring 0 probes --4198-- tt/tc: 0 fast-cache updates, 0 flushes --4198-- transtab: new 0 (0 -> 0; ratio 0.0) [0 scs] avg tce size 0 --4198-- transtab: dumped 0 (0 -> ??) (sectors recycled 0) --4198-- transtab: discarded 0 (0 -> ??) --4198-- scheduler: 0 event checks. --4198-- scheduler: 0 indir transfers, 0 misses (1 in 0) --4198-- scheduler: 0/0 major/minor sched events. --4198-- sanity: 0 cheap, 0 expensive checks. mmap(0x802001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EINVAL (Invalid argument) ==4198== ==4198== Valgrind's memory management: out of memory: ==4198== newSuperblock's request for 4194304 bytes failed. ==4198== 18,939,904 bytes have already been mmap-ed ANONYMOUS. ==4198== Valgrind cannot continue. Sorry. ==4198== ==4198== There are several possible reasons for this. ==4198== - You have some kind of memory limit in place. Look at the ==4198== output of 'ulimit -a'. Is there a limit on the size of ==4198== virtual memory or address space? ==4198== - You have run out of swap space. ==4198== - Valgrind has a bug. If you think this is the case or you are ==4198== not sure, please let us know and we'll try to fix it. ==4198== Please note that programs can take substantially more memory than ==4198== normal when running under Valgrind tools, eg. up to twice or ==4198== more, depending on the tool. On a 64-bit machine, Valgrind ==4198== should be able to make use of up 32GB memory. On a 32-bit ==4198== machine, Valgrind should be able to use all the memory available ==4198== to a single process, up to 4GB if that's how you have your ==4198== kernel configured. Most 32-bit Linux setups allow a maximum of ==4198== 3GB per process. ==4198== ==4198== Whatever the reason, Valgrind cannot continue. Sorry. +++ exited with 1 +++ -- View this message in context: http://valgrind.10908.n7.nabble.com/Why-valgrind-could-not-be-used-on-cavium-octeon3-tp57531p57546.html Sent from the Valgrind - Dev mailing list archive at Nabble.com. |
