It looks like deny_execmem is off by default. At least on my setup:
$ getsebool deny_execmem
deny_execmem --> off

If I enable it my desktop crashes... both gnome-shell and firefox dump core.
Apparently both use a javascript JIT runtime.

Is this a supported setup?
valgrind needs a executable memory for its VEX jit.

It is supported, at least on non-GUI systems.
The issue here is more with dying with another message that not being able to allocate memory (it would be not being able to *execute* memory instead).

(In reply to Renaud Métrich from comment #2)
> It is supported, at least on non-GUI systems.
> The issue here is more with dying with another message that not being able
> to allocate memory (it would be not being able to *execute* memory instead).

Aha, ok, so it is about giving a better error message if deny_execmem is on. That should be doable.

Submitted a patch upstream https://bugs.kde.org/show_bug.cgi?id=464680
With that the error message will show Permission denied and includes a hint about selinux deny_execmem:

==509341== 
==509341==     Valgrind's memory management: out of memory: Permission denied
==509341==        newSuperblock's request for 4194304 bytes failed.
==509341==           27,480,064 bytes have already been mmap-ed ANONYMOUS.
==509341==     Valgrind cannot continue.  Sorry.
==509341== 
==509341==     There are several possible reasons for this.
==509341==     - You have some kind of memory limit in place.  Look at the
==509341==       output of 'ulimit -a'.  Is there a limit on the size of
==509341==       virtual memory or address space?
==509341==     - You have run out of swap space.
==509341==     - You have some policy enabled that denies memory to be
==509341==       executable (for example selinux deny_execmem) that causes
==509341==       mmap to fail with Permission denied.
==509341==     - Valgrind has a bug.  If you think this is the case or you are
==509341==     not sure, please let us know and we'll try to fix it.
==509341==     Please note that programs can take substantially more memory than
==509341==     normal when running under Valgrind tools, eg. up to twice or
==509341==     more, depending on the tool.  On a 64-bit machine, Valgrind
==509341==     should be able to make use of up 32GB memory.  On a 32-bit
==509341==     machine, Valgrind should be able to use all the memory available
==509341==     to a single process, up to 4GB if that's how you have your
==509341==     kernel configured.  Most 32-bit Linux setups allow a maximum of
==509341==     3GB per process.
==509341== 
==509341==     Whatever the reason, Valgrind cannot continue.  Sorry.

Thanks a lot, it's more explanatory now.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (valgrind bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6953