Closed GoogleCodeExporter closed 8 years ago
GoogleCodeExporter
commented
8 years ago This happens to me too. If I pass the --nogui flag, everything seems to exit
normally. Problem is exiting back to the GUI or some such. Please let me know
how I
can help.Original comment by mercs...@gmail.com on 5 Feb 2009 at 3:29
GoogleCodeExporter
commented
8 years ago I sent this patch in a different thread, might as well post it here too. It
does not
fix the real problem, but it gets rid of the need exit X and it enables you to
get a
core file:
--- main.c.old 2009-02-10 11:35:27.000000000 +0100
+++ main.c 2009-02-10 11:36:21.000000000 +0100
@@ -975,7 +975,19 @@
case SEGV_ACCERR: printf( " invalid permissions for
mapped object\n" ); break;
}
#endif
- break;
+
+#ifndef __WIN32__
+ {
+ struct sigaction sa;
+
+ memset( &sa, 0, sizeof( struct sigaction ) );
+ sa.sa_handler = SIG_DFL;
+ sigaction( SIGSEGV, &sa, NULL );
+ }
+ return;
+#else
+ break;
+#endif
case SIGILL:
printf( "SIGILL in core thread caught:\n" );
printf( "\terrno = %d (%s)\n", info->si_errno, strerror( info->si_errno ) );
Original comment by hextrem...@gmail.com on 10 Feb 2009 at 10:44
GoogleCodeExporter
commented
8 years ago I committed a potential fix for this in rev #1321. Please update, rebuild, and
test
again. It will probably still catch a segfault and crash the program but it
shouldn't loop forever.Original comment by richard...@gmail.com on 11 Feb 2009 at 1:30
GoogleCodeExporter
commented
8 years ago Still the same problem in rev #1328. I do not think it's a good idea to
attempt to
continue running a program that is segfaulting....Original comment by hextrem...@gmail.com on 14 Feb 2009 at 10:29
GoogleCodeExporter
commented
8 years ago Yep, you're right. I did a little digging and I see what happened. This got
broken
in the r970-sdl-threads branch, which I merged into the trunk in rev 1009. I
have
just committed rev 1330 which changes this back to a simple abort() call.
Please
test and post your findings here. I cannot duplicate the segfault on my 64-bit
machine.Original comment by richard...@gmail.com on 17 Feb 2009 at 4:03
GoogleCodeExporter
commented
8 years ago The unlimited messages are gone, but mupen64 still crashes when you exit a ROM.
No
settings are saved, etc. You must be close to the problem, but it's not fixed
yet.Original comment by mercs...@gmail.com on 17 Feb 2009 at 6:29
GoogleCodeExporter
commented
8 years ago Unfortunately I'm not close to the real problem - I have no idea what is
causing the
initial segfault. I can try to diagnose this if someone can reproduce the
problem
though:
1. edit the main/main.c file and comment out the lines 829-832, so they look
like:
// sigaction( SIGSEGV, &sa, NULL );
// sigaction( SIGILL, &sa, NULL );
// sigaction( SIGFPE, &sa, NULL );
// sigaction( SIGCHLD, &sa, NULL );
2. recompile mupen64plus, and run in the debugger:
gdb ./mupen64plus
run
3. reproduce the crash, and you should get a prompt in the debugger
4. enter the commands in the debugger: "bt" and then "info registers" and paste
everything from the debugger here.Original comment by richard...@gmail.com on 4 Mar 2009 at 12:49
GoogleCodeExporter
commented
8 years ago Here:
(gdb) bt
#0 0x02c6c32c in ?? ()
#1 0x005205ca in start_thread () from /lib/libpthread.so.0
#2 0x00ed204e in clone () from /lib/libc.so.6
(gdb) info registers
eax 0x2c6c32c 46580524
ecx 0x9f62be8 167128040
edx 0x9e2d7b8 165861304
ebx 0x530ff4 5443572
esp 0xb41ff34c 0xb41ff34c
ebp 0xb41ff438 0xb41ff438
esi 0x6 6
edi 0x531190 5443984
eip 0x2c6c32c 0x2c6c32c
eflags 0x210216 [ PF AF IF RF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
Original comment by mercs...@gmail.com on 4 Mar 2009 at 1:12
GoogleCodeExporter
commented
8 years ago Uh oh, I thought this was a 64-bit problem. From the output that you gave, you
are
running the 32-bit build. There is one other piece of information that I need,
and
that is the code list for the code near the point of failure. To get this, you
need
to use the 'disassemble' command to get an ASM dump of the code. The exact
command
depends upon the location of the crash, but using your previous post as an
example,
the first line in the 'bt' output tells you where the crash happened:
0x2c6c32c. So
take 0x60 bytes before the crash and 0x20 bytes after, and to get the
disassembly you
would do 'disassemble 0x2c6c2cc 0x2c6c34c'Original comment by richard...@gmail.com on 4 Mar 2009 at 1:23
GoogleCodeExporter
commented
8 years ago No, my entire environment is 32bit. My CPU is AMD X2 which is 64bit, but
kernel and
all userland is 32bit. (Fefora 10)
(gdb) bt
#0 0x04c8632c in ?? ()
#1 0x005205ca in start_thread () from /lib/libpthread.so.0
#2 0x0045604e in clone () from /lib/libc.so.6
(gdb) disassemble 0x4C862CC 0x4C8634C
Dump of assembler code from 0x4c862cc to 0x4c8634c:
0x04c862cc: Cannot access memory at address 0x4c862cc
Not sure where I'm going wrong here. Plz advise.
Original comment by mercs...@gmail.com on 4 Mar 2009 at 2:30
GoogleCodeExporter
commented
8 years ago Last night I built the 32-bit version and attempted to reproduce this bug but
still
couldn't. Regarding your 'cannot access memory at' problem, there is one more
thing
that you can try. Instead of subtracting 0x60 from the crash point, try to
disassemble starting exactly at the crash point. Using your last post, this
would be
'disassemble 0x4c8632c 0x4c8634c'. If you still get the same error, then the
dynarec
code has jumped to an illegal memory address. This is much more difficult to
debug.
I presume that if you run with the Interpreter instead of the Dynarec you wouldn't
get this crash.Original comment by richard...@gmail.com on 6 Mar 2009 at 6:43
GoogleCodeExporter
commented
8 years ago This is so sad. Mupen64plus STILL crashes when exiting from a ROM and
returning to
the GUI:
Error: The core thread recieved a SIGSEGV signal.
This means it tried to access protected memory.
Maybe you have set a wrong ucode for one of the plugins!
SIGSEGV in core thread caught:
errno = 0 (Success)
address = 0x02DB132C
address not mapped to object
Aborted
I even switched to Interpreter (not dynamic recompiler) and it happened.
Please, advise.Original comment by mercs...@gmail.com on 27 Mar 2009 at 11:26
GoogleCodeExporter
commented
8 years ago BTW this is NOT a 64-bit problem, my CPU is 64bit-capable but I am running 32bit
Fedora Core 10 with a 32-bit kernel. Please advise.Original comment by mercs...@gmail.com on 27 Mar 2009 at 11:30
GoogleCodeExporter
commented
8 years ago If I disable the jttl audio plugin, mupen64plus does not crash after quitting a
ROM!Original comment by mercs...@gmail.com on 27 Mar 2009 at 11:35
GoogleCodeExporter
commented
8 years ago Well that's a clue. I have not been able to reproduce this problem so it must
be
system-related. I'll look through the shutdown code in jttl and see if I can
find
anything. What is your sound hardware? Which versions of SDL and Alsa do you
have
installed?Original comment by richard...@gmail.com on 28 Mar 2009 at 7:43
GoogleCodeExporter
commented
8 years ago It's definitely sound related; if I set SDL_AUDIODRIVER to esd,asla,dsp etc
mupen64plus does not crash; however sound dropouts cause the ROMs to run at a
very
stuttered pace.
pulseaudio-0.9.14-1.fc10.i386
SDL-1.2.13-7.fc10.i386
Could you recommend settings for the jttl audio plugin that would cut down on
the
amount of dropouts? (i.e. sound stutters, therefore the whole emulation
stutters).
I'd even be willing to cause sound to drop out at any time, if it would not
cause the
main emulation to stutter.
Thanks.Original comment by mercs...@gmail.com on 28 Mar 2009 at 7:53
GoogleCodeExporter
commented
8 years ago Ahhh, pulseaudio. That's not too surprising - many people have had all kinds of
problems and complaints with pulseaudio. So the sound/game playback is fine and
smooth with pulseaudio but stutters with alsa? That's strange. You should
open a
new bug for this issue and give your full system details, because this is
unrelated
to issue #201.Original comment by richard...@gmail.com on 4 Apr 2009 at 2:10
GoogleCodeExporter
commented
8 years ago I think I managed to fix this. In the settings menu for the audio plugin, set
the
volume control to "Internal SDL". OSS is ridiculously outdated, and when using
it I
had at different times ridiculously low FPS, the ROM not loading, and the
endless
SIGSEVs. So far I've had none of these after switching to SDL's mixerOriginal comment by hunterne...@gmail.com on 20 May 2010 at 3:33
Original issue reported on code.google.com by
olejl77@gmail.comon 17 Jan 2009 at 4:00