Menu
▾
▴
valgrind-users
|
From: Zhu, Y. <Yan...@vi...> - 2015-04-10 20:05:08
|
Has anyone seen this error when running valgrind 3.10.1 in a MIPS64 platform?
==1769== Valgrind's memory management: out of memory:
==1769== newSuperblock's request for 4194304 bytes failed.
==1769== 22536192 bytes have already been allocated.
==1769== Valgrind cannot continue. Sorry.
I have enough memory in my system as shown below:
# top
Mem: 167900K used, 1800920K free, 0K shrd, 848K buff, 25840K cached
CPU: 0% usr 0% sys 0% nic 100% idle 0% io 0% irq 0% sirq
Load average: 0.00 0.02 0.05 1/68 1949
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
1899 1 root S 21036 1% 0% /usr/sbin/uia_init
1931 1899 root S 20680 1% 0% /usr/sbin/uia_init
1930 1899 root S 6244 0% 0% zebra -i /tmp/quagga/zebra.pid
1932 1899 root S 5068 0% 0% /usr/sbin/stunnel /etc/stunnel/stunnel
1902 1 root S 2956 0% 0% login
1832 1 root S 2944 0% 0% /usr/sbin/thttpd -C /etc/thttpd.conf -
1834 1 root S 2944 0% 0% /usr/sbin/thttpd -C /etc/thttpd.conf -
1901 1 root S 2892 0% 0% /bin/busybox ash --login
1 0 root S 2828 0% 0% init
1903 1 root S 2828 0% 0% /sbin/syslogd -n
1904 1 root S 2828 0% 0% /sbin/klogd -n
1847 1 root S 2828 0% 0% /usr/sbin/telnetd -l /bin/sh
1949 1901 root R 2828 0% 0% top
163 2 root SW 0 0% 0% [kworker/3:1]
957 2 root SW 0 0% 0% [kworker/0:1]
6 2 root SW 0 0% 0% [kworker/u8:0]
1008 2 root SW 0 0% 0% [kworker/u8:3]
955 2 root SW 0 0% 0% [kworker/1:1]
967 2 root SW 0 0% 0% [kworker/2:1]
9 2 root SW 0 0% 0% [rcu_sched]
# free
total used free shared buffers
Mem: 1968820 168148 1800672 0 848
-/+ buffers: 167300 1801520
Swap: 0 0 0
# ulimit -a
-f: file size (blocks) 36028797018963967
-t: cpu time (seconds) 18446744073709551615
-d: data seg size (kb) 18014398509481983
-s: stack size (kb) 8192
-c: core file size (blocks) 0
-m: resident set size (kb) 18014398509481983
-l: locked memory (kb) 64
-p: processes 7569
-n: file descriptors 1024
-v: address space (kb) 18014398509481983
-w: locks 18446744073709551615
-e: scheduling priority 0
-r: real-time priority 0
I really appreciate if I can get some help.
Thanks,
Yanwen
|
|
From: Philippe W. <phi...@sk...> - 2015-04-10 20:22:10
|
On Fri, 2015-04-10 at 20:04 +0000, Zhu, Yanwen wrote: > Has anyone seen this error when running valgrind 3.10.1 in a MIPS64 > platform? > > > > ==1769== Valgrind's memory management: out of memory: > > ==1769== newSuperblock's request for 4194304 bytes failed. > > ==1769== 22536192 bytes have already been allocated. > > ==1769== Valgrind cannot continue. Sorry. Not seen such a thing (but not having access to a mips platform, it is not easy to see what is going on). What looks really strange is the very low level value of the already allocated bytes. So, maybe the aspacemgr view of the memory mapping is not in sync with the kernel view. Normally, such an OOM produces the state of the memory and the aspacemgr state. More trace would also be useful. So, can you run with -v -v -v -d -d -d and send the full log (if not too big). Also, might be useful to run with --sanity-level=4 as this will report aspacemgr<>kernel desync. Philippe |
|
From: Zhu, Y. <Yan...@vi...> - 2015-04-10 20:26:50
|
Philippe, Thanks for your prompt reply, see below for the output when running with -v -v -v -d -d -d and --sanity-level=4 # valgrind -v -v -v -d -d -d --1955:1:debuglog DebugLog system started by Stage 1, level 3 logging requested --1955:1:launcher no tool requested, defaulting to 'memcheck' --1955:1:launcher no client specified, defaulting platform to 'mips64-linux' --1955:1:launcher launching /usr/lib/valgrind/memcheck-mips64-linux --1955:1:debuglog DebugLog system started by Stage 2 (main), level 3 logging requested --1955:1:main Welcome to Valgrind version 3.10.1 debug logging --1955:1:main Checking current stack is plausible --1955:1:main Checking initial stack was noted --1955:1:main Starting the address space manager --1955:2:aspacem sp_at_startup = 0x007f8a7ca0 (supplied) --1955:2:aspacem minAddr = 0x0004000000 (computed) --1955:2:aspacem maxAddr = 0x00ffffffff (computed) --1955:2:aspacem cStart = 0x0004000000 (computed) --1955:2:aspacem vStart = 0x0082000000 (computed) --1955:2:aspacem suggested_clstack_end = 0x00ff000fff (computed) --1955:2:aspacem <<< SHOW_SEGMENTS: Initial layout (4 segments, 0 segnames) --1955:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --1955:2:aspacem 1: 0004000000-0081ffffff 2016m --1955:2:aspacem 2: RSVN 0082000000-0082000fff 4096 ----- SmFixed --1955:2:aspacem 3: 0082001000-00ffffffff 2015m --1955:2:aspacem >>> --1955:2:aspacem Reading /proc/self/maps --1955:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps (13 segments, 1 segnames) --1955:2:aspacem ( 0) /usr/lib/valgrind/memcheck-mips64-linux --1955:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --1955:2:aspacem 1: 0004000000-000fffffff 192m --1955:2:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074 o=0 (0) --1955:2:aspacem 3: 00103df000-00103dffff 4096 --1955:2:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100 i=2074 o=4063232 (0) --1955:2:aspacem 5: ANON 00103ec000-0011947fff 21m rwx-- --1955:2:aspacem 6: 0011948000-007f886fff 1759m --1955:2:aspacem 7: ANON 007f887000-007f8a7fff 135168 rwx-- --1955:2:aspacem 8: 007f8a8000-007fff6fff 7663616 --1955:2:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x-- --1955:2:aspacem 10: 007fff8000-0081ffffff 32m --1955:2:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed --1955:2:aspacem 12: 0082001000-00ffffffff 2015m --1955:2:aspacem >>> --1955:1:main Address space manager is running --1955:1:main Starting the dynamic memory manager --1955:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 segnames) --1955:0:aspacem ( 0) /usr/lib/valgrind/memcheck-mips64-linux --1955:0:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --1955:0:aspacem 1: 0004000000-000fffffff 192m --1955:0:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074 o=0 (0) --1955:0:aspacem 3: 00103df000-00103dffff 4096 --1955:0:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100 i=2074 o=4063232 (0) --1955:0:aspacem 5: ANON 00103ec000-0011947fff 21m rwx-- --1955:0:aspacem 6: 0011948000-007f886fff 1759m --1955:0:aspacem 7: ANON 007f887000-007f8a7fff 135168 rwx-- --1955:0:aspacem 8: 007f8a8000-007fff6fff 7663616 --1955:0:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x-- --1955:0:aspacem 10: 007fff8000-0081ffffff 32m --1955:0:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed --1955:0:aspacem 12: 0082001000-00ffffffff 2015m --1955:0:aspacem >>> --1955-- 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 12 rzB --1955-- 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 12 rzB --1955-- (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 --1955-- 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 12 rzB --1955-- 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 12 rzB --1955-- translate: fast SP updates identified: 0 ( --%) --1955-- translate: generic_known SP updates identified: 0 ( --%) --1955-- translate: generic_unknown SP updates identified: 0 ( --%) --1955-- tt/tc: 0 tt lookups requiring 0 probes --1955-- tt/tc: 0 fast-cache updates, 0 flushes --1955-- transtab: new 0 (0 -> 0; ratio 0:10) [0 scs] --1955-- transtab: dumped 0 (0 -> ??) --1955-- transtab: discarded 0 (0 -> ??) --1955-- scheduler: 0 event checks. --1955-- scheduler: 0 indir transfers, 0 misses (1 in 0) --1955-- scheduler: 0/0 major/minor sched events. --1955-- sanity: 0 cheap, 0 expensive checks. ==1955== ==1955== Valgrind's memory management: out of memory: ==1955== newSuperblock's request for 4194304 bytes failed. ==1955== 22536192 bytes have already been allocated. ==1955== Valgrind cannot continue. Sorry. ==1955== ==1955== There are several possible reasons for this. ==1955== - You have some kind of memory limit in place. Look at the ==1955== output of 'ulimit -a'. Is there a limit on the size of ==1955== virtual memory or address space? ==1955== - You have run out of swap space. ==1955== - Valgrind has a bug. If you think this is the case or you are ==1955== not sure, please let us know and we'll try to fix it. ==1955== Please note that programs can take substantially more memory than ==1955== normal when running under Valgrind tools, eg. up to twice or ==1955== more, depending on the tool. On a 64-bit machine, Valgrind ==1955== should be able to make use of up 32GB memory. On a 32-bit ==1955== machine, Valgrind should be able to use all the memory available ==1955== to a single process, up to 4GB if that's how you have your ==1955== kernel configured. Most 32-bit Linux setups allow a maximum of ==1955== 3GB per process. ==1955== ==1955== Whatever the reason, Valgrind cannot continue. Sorry. # # # # # # valgrind --sanity-level=4 --1956:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 segnames) --1956:0:aspacem ( 0) /usr/lib/valgrind/memcheck-mips64-linux --1956:0:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --1956:0:aspacem 1: 0004000000-000fffffff 192m --1956:0:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074 o=0 (0) --1956:0:aspacem 3: 00103df000-00103dffff 4096 --1956:0:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100 i=2074 o=4063232 (0) --1956:0:aspacem 5: ANON 00103ec000-0011947fff 21m rwx-- --1956:0:aspacem 6: 0011948000-007f880fff 1759m --1956:0:aspacem 7: ANON 007f881000-007f8a1fff 135168 rwx-- --1956:0:aspacem 8: 007f8a2000-007fff6fff 7688192 --1956:0:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x-- --1956:0:aspacem 10: 007fff8000-0081ffffff 32m --1956:0:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed --1956:0:aspacem 12: 0082001000-00ffffffff 2015m --1956:0:aspacem >>> --1956-- 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 12 rzB --1956-- 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 12 rzB --1956-- (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 --1956-- 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 12 rzB --1956-- 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 12 rzB --1956-- translate: fast SP updates identified: 0 ( --%) --1956-- translate: generic_known SP updates identified: 0 ( --%) --1956-- translate: generic_unknown SP updates identified: 0 ( --%) --1956-- tt/tc: 0 tt lookups requiring 0 probes --1956-- tt/tc: 0 fast-cache updates, 0 flushes --1956-- transtab: new 0 (0 -> 0; ratio 0:10) [0 scs] --1956-- transtab: dumped 0 (0 -> ??) --1956-- transtab: discarded 0 (0 -> ??) --1956-- scheduler: 0 event checks. --1956-- scheduler: 0 indir transfers, 0 misses (1 in 0) --1956-- scheduler: 0/0 major/minor sched events. --1956-- sanity: 0 cheap, 0 expensive checks. ==1956== ==1956== Valgrind's memory management: out of memory: ==1956== newSuperblock's request for 4194304 bytes failed. ==1956== 22536192 bytes have already been allocated. ==1956== Valgrind cannot continue. Sorry. ==1956== ==1956== There are several possible reasons for this. ==1956== - You have some kind of memory limit in place. Look at the ==1956== output of 'ulimit -a'. Is there a limit on the size of ==1956== virtual memory or address space? ==1956== - You have run out of swap space. ==1956== - Valgrind has a bug. If you think this is the case or you are ==1956== not sure, please let us know and we'll try to fix it. ==1956== Please note that programs can take substantially more memory than ==1956== normal when running under Valgrind tools, eg. up to twice or ==1956== more, depending on the tool. On a 64-bit machine, Valgrind ==1956== should be able to make use of up 32GB memory. On a 32-bit ==1956== machine, Valgrind should be able to use all the memory available ==1956== to a single process, up to 4GB if that's how you have your ==1956== kernel configured. Most 32-bit Linux setups allow a maximum of ==1956== 3GB per process. ==1956== ==1956== Whatever the reason, Valgrind cannot continue. Sorry. -----Original Message----- From: Philippe Waroquiers [mailto:phi...@sk...] Sent: Friday, April 10, 2015 4:23 PM To: Zhu, Yanwen Cc: val...@li... Subject: Re: [Valgrind-users] valgrind out of memory error On Fri, 2015-04-10 at 20:04 +0000, Zhu, Yanwen wrote: > Has anyone seen this error when running valgrind 3.10.1 in a MIPS64 > platform? > > > > ==1769== Valgrind's memory management: out of memory: > > ==1769== newSuperblock's request for 4194304 bytes failed. > > ==1769== 22536192 bytes have already been allocated. > > ==1769== Valgrind cannot continue. Sorry. Not seen such a thing (but not having access to a mips platform, it is not easy to see what is going on). What looks really strange is the very low level value of the already allocated bytes. So, maybe the aspacemgr view of the memory mapping is not in sync with the kernel view. Normally, such an OOM produces the state of the memory and the aspacemgr state. More trace would also be useful. So, can you run with -v -v -v -d -d -d and send the full log (if not too big). Also, might be useful to run with --sanity-level=4 as this will report aspacemgr<>kernel desync. Philippe |
|
From: Zhu, Y. <Yan...@vi...> - 2015-04-10 20:27:48
|
Also, I just looked at online: https://www.mail-archive.com/val...@li.../msg02027.html Is it a permission problem? Yanwen -----Original Message----- From: Zhu, Yanwen Sent: Friday, April 10, 2015 4:27 PM To: 'Philippe Waroquiers' Cc: val...@li... Subject: RE: [Valgrind-users] valgrind out of memory error Philippe, Thanks for your prompt reply, see below for the output when running with -v -v -v -d -d -d and --sanity-level=4 # valgrind -v -v -v -d -d -d --1955:1:debuglog DebugLog system started by Stage 1, level 3 logging requested --1955:1:launcher no tool requested, defaulting to 'memcheck' --1955:1:launcher no client specified, defaulting platform to 'mips64-linux' --1955:1:launcher launching /usr/lib/valgrind/memcheck-mips64-linux --1955:1:debuglog DebugLog system started by Stage 2 (main), level 3 logging requested --1955:1:main Welcome to Valgrind version 3.10.1 debug logging --1955:1:main Checking current stack is plausible --1955:1:main Checking initial stack was noted --1955:1:main Starting the address space manager --1955:2:aspacem sp_at_startup = 0x007f8a7ca0 (supplied) --1955:2:aspacem minAddr = 0x0004000000 (computed) --1955:2:aspacem maxAddr = 0x00ffffffff (computed) --1955:2:aspacem cStart = 0x0004000000 (computed) --1955:2:aspacem vStart = 0x0082000000 (computed) --1955:2:aspacem suggested_clstack_end = 0x00ff000fff (computed) --1955:2:aspacem <<< SHOW_SEGMENTS: Initial layout (4 segments, 0 segnames) --1955:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --1955:2:aspacem 1: 0004000000-0081ffffff 2016m --1955:2:aspacem 2: RSVN 0082000000-0082000fff 4096 ----- SmFixed --1955:2:aspacem 3: 0082001000-00ffffffff 2015m --1955:2:aspacem >>> --1955:2:aspacem Reading /proc/self/maps --1955:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps (13 segments, 1 segnames) --1955:2:aspacem ( 0) /usr/lib/valgrind/memcheck-mips64-linux --1955:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --1955:2:aspacem 1: 0004000000-000fffffff 192m --1955:2:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074 o=0 (0) --1955:2:aspacem 3: 00103df000-00103dffff 4096 --1955:2:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100 i=2074 o=4063232 (0) --1955:2:aspacem 5: ANON 00103ec000-0011947fff 21m rwx-- --1955:2:aspacem 6: 0011948000-007f886fff 1759m --1955:2:aspacem 7: ANON 007f887000-007f8a7fff 135168 rwx-- --1955:2:aspacem 8: 007f8a8000-007fff6fff 7663616 --1955:2:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x-- --1955:2:aspacem 10: 007fff8000-0081ffffff 32m --1955:2:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed --1955:2:aspacem 12: 0082001000-00ffffffff 2015m --1955:2:aspacem >>> --1955:1:main Address space manager is running --1955:1:main Starting the dynamic memory manager --1955:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 segnames) --1955:0:aspacem ( 0) /usr/lib/valgrind/memcheck-mips64-linux --1955:0:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --1955:0:aspacem 1: 0004000000-000fffffff 192m --1955:0:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074 o=0 (0) --1955:0:aspacem 3: 00103df000-00103dffff 4096 --1955:0:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100 i=2074 o=4063232 (0) --1955:0:aspacem 5: ANON 00103ec000-0011947fff 21m rwx-- --1955:0:aspacem 6: 0011948000-007f886fff 1759m --1955:0:aspacem 7: ANON 007f887000-007f8a7fff 135168 rwx-- --1955:0:aspacem 8: 007f8a8000-007fff6fff 7663616 --1955:0:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x-- --1955:0:aspacem 10: 007fff8000-0081ffffff 32m --1955:0:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed --1955:0:aspacem 12: 0082001000-00ffffffff 2015m --1955:0:aspacem >>> --1955-- 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 12 rzB --1955-- 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 12 rzB --1955-- (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 --1955-- 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 12 rzB --1955-- 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 12 rzB --1955-- translate: fast SP updates identified: 0 ( --%) --1955-- translate: generic_known SP updates identified: 0 ( --%) --1955-- translate: generic_unknown SP updates identified: 0 ( --%) --1955-- tt/tc: 0 tt lookups requiring 0 probes --1955-- tt/tc: 0 fast-cache updates, 0 flushes --1955-- transtab: new 0 (0 -> 0; ratio 0:10) [0 scs] --1955-- transtab: dumped 0 (0 -> ??) --1955-- transtab: discarded 0 (0 -> ??) --1955-- scheduler: 0 event checks. --1955-- scheduler: 0 indir transfers, 0 misses (1 in 0) --1955-- scheduler: 0/0 major/minor sched events. --1955-- sanity: 0 cheap, 0 expensive checks. ==1955== ==1955== Valgrind's memory management: out of memory: ==1955== newSuperblock's request for 4194304 bytes failed. ==1955== 22536192 bytes have already been allocated. ==1955== Valgrind cannot continue. Sorry. ==1955== ==1955== There are several possible reasons for this. ==1955== - You have some kind of memory limit in place. Look at the ==1955== output of 'ulimit -a'. Is there a limit on the size of ==1955== virtual memory or address space? ==1955== - You have run out of swap space. ==1955== - Valgrind has a bug. If you think this is the case or you are ==1955== not sure, please let us know and we'll try to fix it. ==1955== Please note that programs can take substantially more memory than ==1955== normal when running under Valgrind tools, eg. up to twice or ==1955== more, depending on the tool. On a 64-bit machine, Valgrind ==1955== should be able to make use of up 32GB memory. On a 32-bit ==1955== machine, Valgrind should be able to use all the memory available ==1955== to a single process, up to 4GB if that's how you have your ==1955== kernel configured. Most 32-bit Linux setups allow a maximum of ==1955== 3GB per process. ==1955== ==1955== Whatever the reason, Valgrind cannot continue. Sorry. # # # # # # valgrind --sanity-level=4 --1956:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 segnames) --1956:0:aspacem ( 0) /usr/lib/valgrind/memcheck-mips64-linux --1956:0:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --1956:0:aspacem 1: 0004000000-000fffffff 192m --1956:0:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074 o=0 (0) --1956:0:aspacem 3: 00103df000-00103dffff 4096 --1956:0:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100 i=2074 o=4063232 (0) --1956:0:aspacem 5: ANON 00103ec000-0011947fff 21m rwx-- --1956:0:aspacem 6: 0011948000-007f880fff 1759m --1956:0:aspacem 7: ANON 007f881000-007f8a1fff 135168 rwx-- --1956:0:aspacem 8: 007f8a2000-007fff6fff 7688192 --1956:0:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x-- --1956:0:aspacem 10: 007fff8000-0081ffffff 32m --1956:0:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed --1956:0:aspacem 12: 0082001000-00ffffffff 2015m --1956:0:aspacem >>> --1956-- 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 12 rzB --1956-- 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 12 rzB --1956-- (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 --1956-- 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 12 rzB --1956-- 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 12 rzB --1956-- translate: fast SP updates identified: 0 ( --%) --1956-- translate: generic_known SP updates identified: 0 ( --%) --1956-- translate: generic_unknown SP updates identified: 0 ( --%) --1956-- tt/tc: 0 tt lookups requiring 0 probes --1956-- tt/tc: 0 fast-cache updates, 0 flushes --1956-- transtab: new 0 (0 -> 0; ratio 0:10) [0 scs] --1956-- transtab: dumped 0 (0 -> ??) --1956-- transtab: discarded 0 (0 -> ??) --1956-- scheduler: 0 event checks. --1956-- scheduler: 0 indir transfers, 0 misses (1 in 0) --1956-- scheduler: 0/0 major/minor sched events. --1956-- sanity: 0 cheap, 0 expensive checks. ==1956== ==1956== Valgrind's memory management: out of memory: ==1956== newSuperblock's request for 4194304 bytes failed. ==1956== 22536192 bytes have already been allocated. ==1956== Valgrind cannot continue. Sorry. ==1956== ==1956== There are several possible reasons for this. ==1956== - You have some kind of memory limit in place. Look at the ==1956== output of 'ulimit -a'. Is there a limit on the size of ==1956== virtual memory or address space? ==1956== - You have run out of swap space. ==1956== - Valgrind has a bug. If you think this is the case or you are ==1956== not sure, please let us know and we'll try to fix it. ==1956== Please note that programs can take substantially more memory than ==1956== normal when running under Valgrind tools, eg. up to twice or ==1956== more, depending on the tool. On a 64-bit machine, Valgrind ==1956== should be able to make use of up 32GB memory. On a 32-bit ==1956== machine, Valgrind should be able to use all the memory available ==1956== to a single process, up to 4GB if that's how you have your ==1956== kernel configured. Most 32-bit Linux setups allow a maximum of ==1956== 3GB per process. ==1956== ==1956== Whatever the reason, Valgrind cannot continue. Sorry. -----Original Message----- From: Philippe Waroquiers [mailto:phi...@sk...] Sent: Friday, April 10, 2015 4:23 PM To: Zhu, Yanwen Cc: val...@li... Subject: Re: [Valgrind-users] valgrind out of memory error On Fri, 2015-04-10 at 20:04 +0000, Zhu, Yanwen wrote: > Has anyone seen this error when running valgrind 3.10.1 in a MIPS64 > platform? > > > > ==1769== Valgrind's memory management: out of memory: > > ==1769== newSuperblock's request for 4194304 bytes failed. > > ==1769== 22536192 bytes have already been allocated. > > ==1769== Valgrind cannot continue. Sorry. Not seen such a thing (but not having access to a mips platform, it is not easy to see what is going on). What looks really strange is the very low level value of the already allocated bytes. So, maybe the aspacemgr view of the memory mapping is not in sync with the kernel view. Normally, such an OOM produces the state of the memory and the aspacemgr state. More trace would also be useful. So, can you run with -v -v -v -d -d -d and send the full log (if not too big). Also, might be useful to run with --sanity-level=4 as this will report aspacemgr<>kernel desync. Philippe |
|
From: Philippe W. <phi...@sk...> - 2015-04-10 20:53:46
|
On Fri, 2015-04-10 at 20:27 +0000, Zhu, Yanwen wrote: > Also, I just looked at online: > https://www.mail-archive.com/val...@li.../msg02027.html > > Is it a permission problem? It does not look like. But in any case, it looks like you are running Valgrind as root. This is very unusual, and should not be needed. Apart of that, the trace you gave shows that initialisation of the Valgrind malloc lib fails. A succesful startup of the Valgrind malloc lib would give: --13999:1: main Starting the dynamic memory manager --13999:1:mallocfr newSuperblock at 0x61C35000 (pszB 4194288) owner VALGRIND/core So, can you redo the -v -v -v -d -d -d experiment, but using strace to trace it i.e. strace -f valgrind -v -v -v -d -d -d A succesful startup results in a trace such as: [pid 13912] write(2, "--13912:1: main Starting the "..., 55--13912:1: main Starting the dynamic memory manager ) = 55 [pid 13912] mmap2(0x61e41000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x61e41000 [pid 13912] getpid() = 13912 [pid 13912] write(2, "--13912:1:mallocfr newSuperblock"..., 83--13912:1:mallocfr newSuperblock at 0x61E41000 (pszB 4194288) owner VALGRIND/core ) = 83 which shows the mmap syscall, and the resulting superblock trace. So, can you redo the trial with strace, and give the equivalent traces ? Probably the mmap fails. We can then see which address has been chosen by aspacemgr, the resulting errno, and all that could explain the failure Philippe |
|
From: Zhu, Y. <Yan...@vi...> - 2015-04-10 21:24:49
Attachments:
valgrind.strace.txt
|
Philippe, Please see the attached file for strace -f valgrind -v -v -v -d -d -d output Thanks, Yanwen -----Original Message----- From: Philippe Waroquiers [mailto:phi...@sk...] Sent: Friday, April 10, 2015 4:55 PM To: Zhu, Yanwen Cc: val...@li... Subject: RE: [Valgrind-users] valgrind out of memory error On Fri, 2015-04-10 at 20:27 +0000, Zhu, Yanwen wrote: > Also, I just looked at online: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchiv > e.com_valgrind-2Dusers-40lists.sourceforge.net_msg02027.html&d=AwICaQ& > c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=rAkQlM2psJuhxCfM2RLlYF > 9VSPgnp4OE1EdTCMEFlmc&m=qQDnkR1m0dMIHitUxu0e-9pkjZ-YcvHep9EUNsPqef8&s= > xVzNkqFJ9Olvmbh_F02lcPlsblIrgHs-sufLHrICw58&e= > > Is it a permission problem? It does not look like. But in any case, it looks like you are running Valgrind as root. This is very unusual, and should not be needed. Apart of that, the trace you gave shows that initialisation of the Valgrind malloc lib fails. A succesful startup of the Valgrind malloc lib would give: --13999:1: main Starting the dynamic memory manager --13999:1:mallocfr newSuperblock at 0x61C35000 (pszB 4194288) owner VALGRIND/core So, can you redo the -v -v -v -d -d -d experiment, but using strace to trace it i.e. strace -f valgrind -v -v -v -d -d -d A succesful startup results in a trace such as: [pid 13912] write(2, "--13912:1: main Starting the "..., 55--13912:1: main Starting the dynamic memory manager ) = 55 [pid 13912] mmap2(0x61e41000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x61e41000 [pid 13912] getpid() = 13912 [pid 13912] write(2, "--13912:1:mallocfr newSuperblock"..., 83--13912:1:mallocfr newSuperblock at 0x61E41000 (pszB 4194288) owner VALGRIND/core ) = 83 which shows the mmap syscall, and the resulting superblock trace. So, can you redo the trial with strace, and give the equivalent traces ? Probably the mmap fails. We can then see which address has been chosen by aspacemgr, the resulting errno, and all that could explain the failure Philippe |
|
From: Philippe W. <phi...@sk...> - 2015-04-10 21:32:09
|
On Fri, 2015-04-10 at 21:24 +0000, Zhu, Yanwen wrote: > Philippe, > > Please see the attached file for > strace -f valgrind -v -v -v -d -d -d > output The trace confirms that the mmap syscall is failing: n64_write(--1953:1:main Starting the dynamic memory manager ) = 54 n64_mmap() = -1 EINVAL (Invalid argument) But we do not see the syscall args. Maybe you need to give an argument to strace to have them ? A possible cause could be the page size: as I understand, mips have different page size setup. If your valgrind has been compiled with a pagesize not matching your kernel/setup, then maybe Valgrind might ask wrongly aligned mmap requests, giving then this EINVAL You could then configure/compile valgrind, specifying the correct page size e.g. use the below configure option: --with-pagesize= override detected page size (4, 16 or 64) Philippe |
|
From: Zhu, Y. <Yan...@vi...> - 2015-04-13 20:57:21
|
Julian or Philippe, Can you please confirm if mabi=n32 is currently supported by valgrind or not in MIPS64 platform? My Linux kernel is 64-bits, but our applications have to be built for 32-bits. So I need to get valgrind with mabi=n32 to work in our platform. Thanks, Yanwen -----Original Message----- From: Zhu, Yanwen Sent: Monday, April 13, 2015 9:35 AM To: 'js...@ac...'; Philippe Waroquiers Cc: val...@li... Subject: RE: [Valgrind-users] valgrind out of memory error Even if I build valgrind with page size of 4 which matches my kernel page size, I'm still seeing the same problem. I am building valgrind with option -mabi=n32 for mips64. In the thread below, someone says currently valgrind only supports -mabi=n64 for mips64, is that true? http://valgrind.10908.n7.nabble.com/Valgrind-13854-Cross-compiling-for-Cavium-MIPS64-N32-ABI-td48980.html Thanks, Yanwen -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Monday, April 13, 2015 7:17 AM To: Philippe Waroquiers; Zhu, Yanwen Cc: val...@li... Subject: Re: [Valgrind-users] valgrind out of memory error > A possible cause could be the page size: as I understand, mips have > different page size setup. > If your valgrind has been compiled with a pagesize not matching your > kernel/setup, then maybe Valgrind might ask wrongly aligned mmap > requests, giving then this EINVAL Yes, that would be my guess too. At the time the failure happened there was still a block of 1759MB available: | --1956:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 [..] | --1956:0:aspacem 6: 0011948000-007f880fff 1759m so it is clearly not the case that it has really run out of memory. J |
|
From: Tom H. <to...@co...> - 2015-04-13 21:31:54
|
On 13/04/15 21:57, Zhu, Yanwen wrote: > Can you please confirm if mabi=n32 is currently supported by valgrind or not in MIPS64 platform? My Linux kernel is 64-bits, but our applications have to be built for 32-bits. So I need to get valgrind with mabi=n32 to work in our platform. No, the n32 ABI is not supported currently. There are patches in the bug tracker for it (https://bugs.kde.org/show_bug.cgi?id=345763) but they have not been applied yet. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Philippe W. <phi...@sk...> - 2015-04-10 21:00:01
|
On Fri, 2015-04-10 at 20:48 +0000, Zhu, Yanwen wrote: > From: Maurice van Swaaij [mailto:ma...@bl...] > Sent: Friday, April 10, 2015 4:45 PM > To: Zhu, Yanwen > Cc: val...@li...; Philippe Waroquiers > Subject: Re: [Valgrind-users] valgrind out of memory error > > > > > I remember having a similar issue where a program was using mmap to > allocate (to much) memory rather than malloc (or new). > > Valgrind doesn't track the use of mmap, correct me if I'm wrong, so > might run out of memory while reporting just the usage through malloc. Valgrind tracks the use of mmap. If it would not do it, nothing would work. But for sure, the memory mmap-ed by the client is not counted in e.g. the memcheck heap reports. Philippe |
|
From: Maurice v. S. <ma...@bl...> - 2015-04-10 21:02:55
|
I remember having a similar issue where a program was using mmap to allocate (to much) memory rather than malloc (or new). Valgrind doesn't track the use of mmap, correct me if I'm wrong, so might run out of memory while reporting just the usage through malloc. ][ Maurice van Swaaij, Blue Sky Studios ][ ----- Original Message ----- | From: "Yanwen Zhu" <Yan...@vi...> | To: "Philippe Waroquiers" <phi...@sk...> | Cc: val...@li... | Sent: Friday, April 10, 2015 4:27:39 PM | Subject: Re: [Valgrind-users] valgrind out of memory error | Also, I just looked at online: | https://www.mail-archive.com/val...@li.../msg02027.html | Is it a permission problem? | Yanwen | -----Original Message----- | From: Zhu, Yanwen | Sent: Friday, April 10, 2015 4:27 PM | To: 'Philippe Waroquiers' | Cc: val...@li... | Subject: RE: [Valgrind-users] valgrind out of memory error | Philippe, | Thanks for your prompt reply, see below for the output when running | with -v -v -v -d -d -d and --sanity-level=4 | # valgrind -v -v -v -d -d -d | --1955:1:debuglog DebugLog system started by Stage 1, level 3 logging | requested --1955:1:launcher no tool requested, defaulting to | 'memcheck' | --1955:1:launcher no client specified, defaulting platform to | 'mips64-linux' | --1955:1:launcher launching /usr/lib/valgrind/memcheck-mips64-linux | --1955:1:debuglog DebugLog system started by Stage 2 (main), level 3 | logging requested | --1955:1:main Welcome to Valgrind version 3.10.1 debug logging | --1955:1:main Checking current stack is plausible | --1955:1:main Checking initial stack was noted | --1955:1:main Starting the address space manager | --1955:2:aspacem sp_at_startup = 0x007f8a7ca0 (supplied) | --1955:2:aspacem minAddr = 0x0004000000 (computed) | --1955:2:aspacem maxAddr = 0x00ffffffff (computed) | --1955:2:aspacem cStart = 0x0004000000 (computed) | --1955:2:aspacem vStart = 0x0082000000 (computed) | --1955:2:aspacem suggested_clstack_end = 0x00ff000fff (computed) | --1955:2:aspacem <<< SHOW_SEGMENTS: Initial layout (4 segments, 0 | segnames) | --1955:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed | --1955:2:aspacem 1: 0004000000-0081ffffff 2016m | --1955:2:aspacem 2: RSVN 0082000000-0082000fff 4096 ----- SmFixed | --1955:2:aspacem 3: 0082001000-00ffffffff 2015m | --1955:2:aspacem >>> | --1955:2:aspacem Reading /proc/self/maps | --1955:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps | (13 segments, 1 segnames) | --1955:2:aspacem ( 0) /usr/lib/valgrind/memcheck-mips64-linux | --1955:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed | --1955:2:aspacem 1: 0004000000-000fffffff 192m | --1955:2:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 | i=2074 o=0 (0) | --1955:2:aspacem 3: 00103df000-00103dffff 4096 | --1955:2:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100 | i=2074 o=4063232 (0) | --1955:2:aspacem 5: ANON 00103ec000-0011947fff 21m rwx-- | --1955:2:aspacem 6: 0011948000-007f886fff 1759m | --1955:2:aspacem 7: ANON 007f887000-007f8a7fff 135168 rwx-- | --1955:2:aspacem 8: 007f8a8000-007fff6fff 7663616 | --1955:2:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x-- | --1955:2:aspacem 10: 007fff8000-0081ffffff 32m | --1955:2:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed | --1955:2:aspacem 12: 0082001000-00ffffffff 2015m | --1955:2:aspacem >>> | --1955:1:main Address space manager is running | --1955:1:main Starting the dynamic memory manager | --1955:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 | segnames) --1955:0:aspacem ( 0) | /usr/lib/valgrind/memcheck-mips64-linux | --1955:0:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed | --1955:0:aspacem 1: 0004000000-000fffffff 192m | --1955:0:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 | i=2074 o=0 (0) | --1955:0:aspacem 3: 00103df000-00103dffff 4096 | --1955:0:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100 | i=2074 o=4063232 (0) | --1955:0:aspacem 5: ANON 00103ec000-0011947fff 21m rwx-- | --1955:0:aspacem 6: 0011948000-007f886fff 1759m | --1955:0:aspacem 7: ANON 007f887000-007f8a7fff 135168 rwx-- | --1955:0:aspacem 8: 007f8a8000-007fff6fff 7663616 | --1955:0:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x-- | --1955:0:aspacem 10: 007fff8000-0081ffffff 32m | --1955:0:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed | --1955:0:aspacem 12: 0082001000-00ffffffff 2015m | --1955:0:aspacem >>> | --1955-- 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 12 rzB | --1955-- 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 12 rzB | --1955-- (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 | --1955-- 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 12 | rzB | --1955-- 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 12 rzB | --1955-- translate: fast SP updates identified: 0 ( --%) | --1955-- translate: generic_known SP updates identified: 0 ( --%) | --1955-- translate: generic_unknown SP updates identified: 0 ( --%) | --1955-- tt/tc: 0 tt lookups requiring 0 probes | --1955-- tt/tc: 0 fast-cache updates, 0 flushes | --1955-- transtab: new 0 (0 -> 0; ratio 0:10) [0 scs] | --1955-- transtab: dumped 0 (0 -> ??) | --1955-- transtab: discarded 0 (0 -> ??) | --1955-- scheduler: 0 event checks. | --1955-- scheduler: 0 indir transfers, 0 misses (1 in 0) | --1955-- scheduler: 0/0 major/minor sched events. | --1955-- sanity: 0 cheap, 0 expensive checks. | ==1955== | ==1955== Valgrind's memory management: out of memory: | ==1955== newSuperblock's request for 4194304 bytes failed. | ==1955== 22536192 bytes have already been allocated. | ==1955== Valgrind cannot continue. Sorry. | ==1955== | ==1955== There are several possible reasons for this. | ==1955== - You have some kind of memory limit in place. Look at the | ==1955== output of 'ulimit -a'. Is there a limit on the size of | ==1955== virtual memory or address space? | ==1955== - You have run out of swap space. | ==1955== - Valgrind has a bug. If you think this is the case or you | are | ==1955== not sure, please let us know and we'll try to fix it. | ==1955== Please note that programs can take substantially more memory | than | ==1955== normal when running under Valgrind tools, eg. up to twice or | ==1955== more, depending on the tool. On a 64-bit machine, Valgrind | ==1955== should be able to make use of up 32GB memory. On a 32-bit | ==1955== machine, Valgrind should be able to use all the memory | available | ==1955== to a single process, up to 4GB if that's how you have your | ==1955== kernel configured. Most 32-bit Linux setups allow a maximum | of | ==1955== 3GB per process. | ==1955== | ==1955== Whatever the reason, Valgrind cannot continue. Sorry. | # | # | # | # | # | # valgrind --sanity-level=4 | --1956:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 | segnames) --1956:0:aspacem ( 0) | /usr/lib/valgrind/memcheck-mips64-linux | --1956:0:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed | --1956:0:aspacem 1: 0004000000-000fffffff 192m | --1956:0:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 | i=2074 o=0 (0) | --1956:0:aspacem 3: 00103df000-00103dffff 4096 | --1956:0:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100 | i=2074 o=4063232 (0) | --1956:0:aspacem 5: ANON 00103ec000-0011947fff 21m rwx-- | --1956:0:aspacem 6: 0011948000-007f880fff 1759m | --1956:0:aspacem 7: ANON 007f881000-007f8a1fff 135168 rwx-- | --1956:0:aspacem 8: 007f8a2000-007fff6fff 7688192 | --1956:0:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x-- | --1956:0:aspacem 10: 007fff8000-0081ffffff 32m | --1956:0:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed | --1956:0:aspacem 12: 0082001000-00ffffffff 2015m | --1956:0:aspacem >>> | --1956-- 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 12 rzB | --1956-- 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 12 rzB | --1956-- (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 | --1956-- 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 12 | rzB | --1956-- 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 12 rzB | --1956-- translate: fast SP updates identified: 0 ( --%) | --1956-- translate: generic_known SP updates identified: 0 ( --%) | --1956-- translate: generic_unknown SP updates identified: 0 ( --%) | --1956-- tt/tc: 0 tt lookups requiring 0 probes | --1956-- tt/tc: 0 fast-cache updates, 0 flushes | --1956-- transtab: new 0 (0 -> 0; ratio 0:10) [0 scs] | --1956-- transtab: dumped 0 (0 -> ??) | --1956-- transtab: discarded 0 (0 -> ??) | --1956-- scheduler: 0 event checks. | --1956-- scheduler: 0 indir transfers, 0 misses (1 in 0) | --1956-- scheduler: 0/0 major/minor sched events. | --1956-- sanity: 0 cheap, 0 expensive checks. | ==1956== | ==1956== Valgrind's memory management: out of memory: | ==1956== newSuperblock's request for 4194304 bytes failed. | ==1956== 22536192 bytes have already been allocated. | ==1956== Valgrind cannot continue. Sorry. | ==1956== | ==1956== There are several possible reasons for this. | ==1956== - You have some kind of memory limit in place. Look at the | ==1956== output of 'ulimit -a'. Is there a limit on the size of | ==1956== virtual memory or address space? | ==1956== - You have run out of swap space. | ==1956== - Valgrind has a bug. If you think this is the case or you | are | ==1956== not sure, please let us know and we'll try to fix it. | ==1956== Please note that programs can take substantially more memory | than | ==1956== normal when running under Valgrind tools, eg. up to twice or | ==1956== more, depending on the tool. On a 64-bit machine, Valgrind | ==1956== should be able to make use of up 32GB memory. On a 32-bit | ==1956== machine, Valgrind should be able to use all the memory | available | ==1956== to a single process, up to 4GB if that's how you have your | ==1956== kernel configured. Most 32-bit Linux setups allow a maximum | of | ==1956== 3GB per process. | ==1956== | ==1956== Whatever the reason, Valgrind cannot continue. Sorry. | -----Original Message----- | From: Philippe Waroquiers [mailto:phi...@sk...] | Sent: Friday, April 10, 2015 4:23 PM | To: Zhu, Yanwen | Cc: val...@li... | Subject: Re: [Valgrind-users] valgrind out of memory error | On Fri, 2015-04-10 at 20:04 +0000, Zhu, Yanwen wrote: | > Has anyone seen this error when running valgrind 3.10.1 in a MIPS64 | > platform? | > | > | > | > ==1769== Valgrind's memory management: out of memory: | > | > ==1769== newSuperblock's request for 4194304 bytes failed. | > | > ==1769== 22536192 bytes have already been allocated. | > | > ==1769== Valgrind cannot continue. Sorry. | Not seen such a thing (but not having access to a mips platform, it | is not easy to see what is going on). | What looks really strange is the very low level value of the already | allocated bytes. | So, maybe the aspacemgr view of the memory mapping is not in sync | with the kernel view. | Normally, such an OOM produces the state of the memory and the | aspacemgr state. | More trace would also be useful. | So, can you run with | -v -v -v -d -d -d | and send the full log (if not too big). | Also, might be useful to run with | --sanity-level=4 | as this will report aspacemgr<>kernel desync. | Philippe | ------------------------------------------------------------------------------ | BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT | Develop your own process in accordance with the BPMN 2 standard | Learn Process modeling best practices with Bonita BPM through live | exercises | http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- | event?utm_ | source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF | _______________________________________________ | Valgrind-users mailing list | Val...@li... | https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Zhu, Y. <Yan...@vi...> - 2015-04-10 21:39:50
|
What argument should I give to strace in order to get syscall args? Yanwen -----Original Message----- From: Philippe Waroquiers [mailto:phi...@sk...] Sent: Friday, April 10, 2015 5:33 PM To: Zhu, Yanwen Cc: val...@li... Subject: RE: [Valgrind-users] valgrind out of memory error On Fri, 2015-04-10 at 21:24 +0000, Zhu, Yanwen wrote: > Philippe, > > Please see the attached file for > strace -f valgrind -v -v -v -d -d -d > output The trace confirms that the mmap syscall is failing: n64_write(--1953:1:main Starting the dynamic memory manager ) = 54 n64_mmap() = -1 EINVAL (Invalid argument) But we do not see the syscall args. Maybe you need to give an argument to strace to have them ? A possible cause could be the page size: as I understand, mips have different page size setup. If your valgrind has been compiled with a pagesize not matching your kernel/setup, then maybe Valgrind might ask wrongly aligned mmap requests, giving then this EINVAL You could then configure/compile valgrind, specifying the correct page size e.g. use the below configure option: --with-pagesize= override detected page size (4, 16 or 64) Philippe |
|
From: Philippe W. <phi...@sk...> - 2015-04-10 21:45:20
|
On Fri, 2015-04-10 at 21:39 +0000, Zhu, Yanwen wrote:
> What argument should I give to strace in order to get syscall args?
No idea.
On my linux box, a normal strace gives the mmap args.
Try to look at
strace --help
or
man strace
Philippe
|
|
From: Julian S. <js...@ac...> - 2015-04-13 11:16:38
|
> A possible cause could be the page size: as I understand, > mips have different page size setup. > If your valgrind has been compiled with a pagesize > not matching your kernel/setup, then maybe Valgrind might ask > wrongly aligned mmap requests, giving then this EINVAL Yes, that would be my guess too. At the time the failure happened there was still a block of 1759MB available: | --1956:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 [..] | --1956:0:aspacem 6: 0011948000-007f880fff 1759m so it is clearly not the case that it has really run out of memory. J |
|
From: Zhu, Y. <Yan...@vi...> - 2015-04-13 13:35:14
|
Even if I build valgrind with page size of 4 which matches my kernel page size, I'm still seeing the same problem. I am building valgrind with option -mabi=n32 for mips64. In the thread below, someone says currently valgrind only supports -mabi=n64 for mips64, is that true? http://valgrind.10908.n7.nabble.com/Valgrind-13854-Cross-compiling-for-Cavium-MIPS64-N32-ABI-td48980.html Thanks, Yanwen -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Monday, April 13, 2015 7:17 AM To: Philippe Waroquiers; Zhu, Yanwen Cc: val...@li... Subject: Re: [Valgrind-users] valgrind out of memory error > A possible cause could be the page size: as I understand, mips have > different page size setup. > If your valgrind has been compiled with a pagesize not matching your > kernel/setup, then maybe Valgrind might ask wrongly aligned mmap > requests, giving then this EINVAL Yes, that would be my guess too. At the time the failure happened there was still a block of 1759MB available: | --1956:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 [..] | --1956:0:aspacem 6: 0011948000-007f880fff 1759m so it is clearly not the case that it has really run out of memory. J |
Thanks for helping keep SourceForge clean.
X