Also, I just looked at online: https://www.mail-archive.com/valgrind-users@lists.sourceforge.net/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: valgrind-users@lists.sourceforge.net 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:philippe.waroqui...@skynet.be] Sent: Friday, April 10, 2015 4:23 PM To: Zhu, Yanwen Cc: valgrind-users@lists.sourceforge.net 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
