Hide Forgot
# setsebool deny_execmem on # /usr/bin/valgrind /bin/ls ==26552== ==26552== Valgrind's memory management: out of memory: ==26552== newSuperblock's request for 4194304 bytes failed. ==26552== 43847680 bytes have already been allocated. ==26552== Valgrind cannot continue. Sorry. ==26552== ==26552== There are several possible reasons for this. ==26552== - You have some kind of memory limit in place. Look at the ==26552== output of 'ulimit -a'. Is there a limit on the size of ==26552== virtual memory or address space? ==26552== - You have run out of swap space. ==26552== - Valgrind has a bug. If you think this is the case or you are ==26552== not sure, please let us know and we'll try to fix it. ==26552== Please note that programs can take substantially more memory than ==26552== normal when running under Valgrind tools, eg. up to twice or ==26552== more, depending on the tool. On a 64-bit machine, Valgrind ==26552== should be able to make use of up 32GB memory. On a 32-bit ==26552== machine, Valgrind should be able to use all the memory available ==26552== to a single process, up to 4GB if that's how you have your ==26552== kernel configured. Most 32-bit Linux setups allow a maximum of ==26552== 3GB per process. ==26552== ==26552== Whatever the reason, Valgrind cannot continue. Sorry. # ls -lZ /usr/bin/valgrind -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/valgrind On rhel 6 valgrind has execmem_exec_t context, this does not work on rhel7 for some reason.
This seems to be a problem on Fedora as well.
So you are reporting we don't have execmem_exec_t label in RHEL7. This is expected in RHEL7.
(In reply to Miroslav Grepl from comment #2) > So you are reporting we don't have execmem_exec_t label in RHEL7. This is > expected in RHEL7. Does that mean that under RHEL7 there is nothing special valgrind has to do for selinux to be able to use writable executable segments (which it needs for the generated code)?
Yes. sh-4.2# getsebool -a |grep deny deny_execmem --> off is by default.