Crash with segfault when rwx pages are not available

[GoogleCodeExporter]

Describe your system:
 - Operating System (be specific): Fedora Core 13
 - Machine type (32-bit or 64-bit): 64-bit
 - Mupen64Plus version: 1.99.3
- Plugins used:

Describe the problem:

Core Error: Memory error: couldn't set RWX permissions on 266448 byte block of 
memory.
Segmentation fault (core dumped)

Mupen64plus crash and gives the errors provided above, a solution might be to 
add "--emumode 0" to the program as an argument.

Example:
$ ./mupen64plus --emumode 0 example.n64

Original issue reported on code.google.com by geekiebe...@gmail.com on 14 Aug 2010 at 9:33

[GoogleCodeExporter]

I just thought of this - have you tried running it as a super user (sudo)? You 
shouldn't have trouble setting permissions as sudo.

Try sudo mupen64plus example.n64

Original comment by spinout_...@yahoo.com on 14 Aug 2010 at 11:12

[GoogleCodeExporter]

What type of CPU and how much RAM do you have?

Original comment by richard...@gmail.com on 15 Aug 2010 at 12:06

[GoogleCodeExporter]

I am having this exact same issue on a 64-bit system running Fedora 13 and the 
same version of mupen64plus. My computer has an Intel Core i7 CPU (2Mhz 
quad-core) with 6GB of RAM. 

Using the "--emumode 0" argument does enable it to run but the resulting 
emulation is extremely slow to the point of being unplayable.

I have tried using the binaries as well as building from source and encountered 
the same error. Running the program as root also seems to have no effect on 
this error.

Let me know if there's any more info that could help you diagnose the problem.

Original comment by dssh...@gmail.com on 8 Oct 2010 at 11:30

[GoogleCodeExporter]

266448 dont look me like the size of a page. Could you please try to generate a 
stacktrace (with an CFLAGS="-O0 -g3" CXXFLAGS="-O0 -g3" build). Also try the hg 
version. Best way is to use a local dir where you install all mupen64plus 
files. Check that you don't have global mupen64plus files installed in your 
/usr/lib/, /usr/lib/mupen64plus and similar paths.

Does this happen on all roms you have or only when using some special one?

The output also says that the core was dumped. Can you please upload the 
core-dump + all mupen64plus binaries you used somewhere? You can also enable 
core dumping with `ulimit -c unlimited` in the shell you will start the 
mupen64plus test.

Original comment by sven@narfation.org on 9 Oct 2010 at 7:33

[GoogleCodeExporter]

I'm having the exact same issue with Fedora 13 (64-bit) and Mupen64plus 1.99.3. 
I've tried running as normal user and as root, which doesn't appear to make a 
difference.

I'll try muellhierrein's suggestions when I have some time. Where does the core 
dump to if that would be useful to upload?

Attached is the console/terminal output when trying to run the test script.

Original comment by alex.d.w...@gmail.com on 1 Nov 2010 at 12:10

Attachments:

• mupen64plus_01

[GoogleCodeExporter]

I'm getting the same error, including the same size block.  I just compiled 
from hg on Fedora 14 x86_64.  I edited the mupen64plus-core/src/r4300/recomp.c 
file to call perror() after the failed mprotect call, and the resulting error 
is "Permission denied".  I've tried running as root and still get the same 
error.  Using emumode=0 does allow it to run, but its a bit too slow to use.  

Seems the root of the problem is with selinux.  I turned it off with `echo 0 > 
/selinux/enforce` and now the emulator runs fine.  I turned selinux back on 
then took the PROT_EXEC flag out of the mprotect function call, and it was able 
to complete successfully (but obviously fail quickly for other reasons).  So it 
seems selinux, on Fedora at least, does not allow setting memory executable.  
I'm assuming there should be some way to tell selinux to allow this for this 
one program, but I don't know how.

My hardware is Core i7 920 clocked at 3GHz with 6GB of ram and a ATI radeon 
HD4850. I am running kernel 2.6.37-rc3 and a mesa git snapshot from Nov 22 with 
the r660g driver.  

Original comment by zman0...@gmail.com on 23 Nov 2010 at 9:20

[GoogleCodeExporter]

From http://www.akkadia.org/drepper/selinux-mem.html :

execheap
The POSIX specification does not permit it, but the Linux implementation of 
mprotect allows changing the access protection of memory on the heap (e.g., 
allocated using malloc). This error indicates that heap memory was supposed to 
be made executable. Doing this is really a bad idea. If anonymous, executable 
memory is needed it should be allocated using mmap which is the only portable 
mechanism.

Also, from http://opengroup.org/onlinepubs/007908799/xsh/mprotect.html :

The behaviour of this function is unspecified if the mapping was not 
established by a call to mmap().

Would it be possible to use mmap() instead of valloc() to allocate this block 
of memory?

Original comment by zman0...@gmail.com on 23 Nov 2010 at 9:46

[GoogleCodeExporter]

Original comment by richard...@gmail.com on 29 Dec 2010 at 1:08

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by richard...@gmail.com on 22 May 2011 at 4:27

• Added labels: Milestone-2.0

[GoogleCodeExporter]

432d55e201d5 switches to rw pages for cached interpreter (this allows cached + 
pure interpreter on machines without rwx pages).
49d1ea0dc0b2 informs the user about the possibility to use an interpreter mode 
when rwx pages are not available.
bc034c4e3e07 allocates rwx pages with anonymous mmapping instead of using 
valloc and mprotect.

Could this please be tested? (They are currently only available through 
https://bitbucket.org/lazhur/mupen64plus-core )

Original comment by sven@narfation.org on 10 Jul 2011 at 9:46

[GoogleCodeExporter]

Original comment by sven@narfation.org on 10 Jul 2011 at 9:47

• Changed title: Crash with segfault when rwx pages are not available

[GoogleCodeExporter]

It is now merged in https://bitbucket.org/richard42

Original comment by s...@narfation.org on 15 Jul 2011 at 12:14

[GoogleCodeExporter]

I have tested the changes. (And I must say, it's quite a chore to fetch all the 
repositories of these individual libraries and compile/install them. But I 
really want this to work.)

Anyway, verified that it works on Fedora 15! Thanks for the patch.

Original comment by VincentB...@gmail.com on 17 Jul 2011 at 12:00

[GoogleCodeExporter]

Thanks for the verification

And we have helper scripts for the fetching and compilation: 
http://code.google.com/p/mupen64plus/wiki/CompilingFromHg

Original comment by s...@narfation.org on 17 Jul 2011 at 7:47

• Changed state: Verified

[GoogleCodeExporter]

Issue 471 has been merged into this issue.

Original comment by s...@narfation.org on 7 Dec 2011 at 1:46

[GoogleCodeExporter]

Issue 474 has been merged into this issue.

Original comment by s...@narfation.org on 8 Jan 2012 at 7:23