Closed GoogleCodeExporter closed 8 years ago
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
What type of CPU and how much RAM do you have?
Original comment by richard...@gmail.com
on 15 Aug 2010 at 12:06
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
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
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:
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
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
Original comment by richard...@gmail.com
on 29 Dec 2010 at 1:08
Original comment by richard...@gmail.com
on 22 May 2011 at 4:27
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
Original comment by sven@narfation.org
on 10 Jul 2011 at 9:47
It is now merged in https://bitbucket.org/richard42
Original comment by s...@narfation.org
on 15 Jul 2011 at 12:14
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
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
Issue 471 has been merged into this issue.
Original comment by s...@narfation.org
on 7 Dec 2011 at 1:46
Issue 474 has been merged into this issue.
Original comment by s...@narfation.org
on 8 Jan 2012 at 7:23
Original issue reported on code.google.com by
geekiebe...@gmail.com
on 14 Aug 2010 at 9:33