|
From: Aki T. <cm...@de...> - 2010-10-07 05:32:59
|
I am getting an error which prevents valgrind from starting. I am running kernel 2.6.32.22 under Ubuntu 10.04 ==10577== ==10577== Valgrind's memory management: out of memory: ==10577== newSuperblock's request for 4194304 bytes failed. ==10577== 14356480 bytes have already been allocated. ==10577== Valgrind cannot continue. Sorry. ==10577== ==10577== There are several possible reasons for this. ==10577== - You have some kind of memory limit in place. Look at the ==10577== output of 'ulimit -a'. Is there a limit on the size of ==10577== virtual memory or address space? ==10577== - You have run out of swap space. ==10577== - Valgrind has a bug. If you think this is the case or you are ==10577== not sure, please let us know and we'll try to fix it. ==10577== Please note that programs can take substantially more memory than ==10577== normal when running under Valgrind tools, eg. up to twice or ==10577== more, depending on the tool. On a 64-bit machine, Valgrind ==10577== should be able to make use of up 32GB memory. On a 32-bit ==10577== machine, Valgrind should be able to use all the memory available ==10577== to a single process, up to 4GB if that's how you have your ==10577== kernel configured. Most 32-bit Linux setups allow a maximum of ==10577== 3GB per process. ==10577== ==10577== Whatever the reason, Valgrind cannot continue. Sorry. $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 20 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited |
|
From: WAROQUIERS P. <phi...@eu...> - 2010-10-07 10:48:13
|
At work, we encountered 'not enough memory' crashes of our big application under valgrind due to the way the superblocks are managed (see bug http://bugs.kde.org/show_bug.cgi?id=250101 (there is a proposed patch to solve this bug) However, in your case, not being able to even allocate about 20 Mb ((14.3Mb + 4.2 Mb) looks really strange : >==10577== >==10577== Valgrind's memory management: out of memory: >==10577== newSuperblock's request for 4194304 bytes failed. >==10577== 14356480 bytes have already been allocated. >==10577== Valgrind cannot continue. Sorry. So, it is unclear what is happening. Maybe the best is to enable the debug traces of valgrind to have more details. If still not clear, strace of valgrind might give even more details about the system calls leading to the above failure. Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Aki T. <cm...@de...> - 2010-10-07 11:28:50
|
On Thu, Oct 07, 2010 at 12:21:57PM +0200, WAROQUIERS Philippe wrote: > > At work, we encountered 'not enough memory' crashes of our big > application > under valgrind due to the way the superblocks are managed (see bug > http://bugs.kde.org/show_bug.cgi?id=250101 > (there is a proposed patch to solve this bug) > > However, in your case, not being able to even allocate about 20 Mb > ((14.3Mb + 4.2 Mb) looks really strange : > > >==10577== > >==10577== Valgrind's memory management: out of memory: > >==10577== newSuperblock's request for 4194304 bytes failed. > >==10577== 14356480 bytes have already been allocated. > >==10577== Valgrind cannot continue. Sorry. > > > So, it is unclear what is happening. Maybe the best is to enable > the debug traces of valgrind to have more details. > If still not clear, strace of valgrind might give even more details > about the system calls leading to the above failure. > > Philippe > Should've though strace myself. The problem is execve("/usr/lib/valgrind/memcheck-amd64-linux", ["/usr/bin/valgrind.bin"], [/* 39 vars */]) = 0 open("/proc/self/maps", O_RDONLY) = 3 read(3, "38000000-381f5000 r-xp 00000000 "..., 100000) = 549 read(3, "", 99451) = 0 close(3) = 0 mmap(0x402001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EPERM (Operation not permitted) getpid() = 27233 This is probably due to grsecurity kernel but I am not sure why, it has worked before on a 32 bit system. Aki Tuomi |
|
From: WAROQUIERS P. <phi...@eu...> - 2010-10-07 15:23:24
|
>mmap(0x402001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, >MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EPERM >(Operation not permitted) >getpid() = 27233 > >This is probably due to grsecurity kernel but I am not sure >why, it has worked >before on a 32 bit system. According to the mmap manual on my system (red-hat 5.2), EPERM on mmap means: PROT_EXEC asked but mapped file is on a file system mounted no-exec. But the call above does not map a file. The documentation also says that if MAP_ANONYMOUS is given, the fd arg is ignored but that some implementations require fd to be -1 in this case and recommends that portable implementations gives -1. (it looks like valgrind does not follow this recommendation, but it is unclear if that is the cause of your problem). I guess it is easy to patch valgrind to give -1 instead of 0 for map_anonymous. But the grsecurity features are probably the most probably guilty. Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Aki T. <cm...@de...> - 2010-10-08 17:23:32
|
On Thu, Oct 07, 2010 at 05:23:12PM +0200, WAROQUIERS Philippe wrote: > >mmap(0x402001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, > >MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EPERM > >(Operation not permitted) > >getpid() = 27233 > > > >This is probably due to grsecurity kernel but I am not sure > >why, it has worked > >before on a 32 bit system. > According to the mmap manual on my system (red-hat 5.2), > EPERM on mmap means: > PROT_EXEC asked but mapped file is on a file system mounted no-exec. > > But the call above does not map a file. > The documentation also says that if MAP_ANONYMOUS is given, the fd arg > is ignored but that some implementations require fd to be -1 in this > case > and recommends that portable implementations gives -1. > (it looks like valgrind does not follow this recommendation, but it is > unclear > if that is the cause of your problem). I guess it is easy to patch > valgrind > to give -1 instead of 0 for map_anonymous. > > But the grsecurity features are probably the most probably guilty. > > Philippe > Yep. It seems that grsecurity has nowadays feature which prevents any RWX mappings silently. Luckily paxctl -m disables that. Hope this helps anyone else who runs into this. Although you need to do that for Yep. It seems that grsecurity has nowadays feature which prevents any RWX mappings silently. Luckily paxctl -m disables that. Hope this helps anyone else who runs into this. Although you need to do that for /usr/lib/valgrind/memcheck-amd64-linux or equivalent, as it execve's this and it's the actual failing binary. Aki Tuomi |