Emulator

Check Issue 2053, sounds like the same problem.

Just ran it with debug packages on another computer(Fedora 11). It gave me this
information:

41:56:072
Source/Core/Core/Src/PowerPC/Interpreter/Interpreter_SystemRegisters.cpp:344
N[PowerPC]: Flush Instruction Cache! ICE=0
41:56:094
Source/Core/Core/Src/PowerPC/Interpreter/Interpreter_SystemRegisters.cpp:335
N[PowerPC]: Instruction Cache Enable (HID0.ICE) = 1
Dolphin: xcb_io.c:242: process_responses: Assertion `(((long)
(dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
Multiple segmentation faults occurred; can't display error dialog

** (bug-buddy:10534): WARNING **: Could not read /proc/10499/exe: Failed to read the
symbolic link '/proc/10499/exe': Permission denied

/usr/libexec/Dolphin: No such file or directory.
ptrace: No such process.
/home/Zander/dolphin/dolphin-emu-read-only/Binary/Linux-x86_64/10499: No such file or
directory.
No stack.

Not the same problem because it's segfault-ing on two of my computers both with
dual-core enabled. changing options doesn't affect it. I'm using Fedora 11 with
FGLRX(ati graphics) on the one computer, and on the other I'm using Fedora 12 with
the OSS radeon graphics(i don't expect this one to run, but it segfaults at the same
spot as the other computer which used to run dolphin just fine)

rev 4890 works, the next rev that compiles on linux(4894) does not work... so i'm
guessing it had to do with the JIT JITIL merge... i'm going to look into and see if i
can't get it fixed...

Issue 2199 has been merged into this issue.

The xcb assert seems to be some sort of threading problem.

Someone on a real linux please try this out:
http://pastebin.com/f1668e031
My VM can't create a glx context for some reason, and thus fails to create the
rendering window.

I just gave it a shot, but it's not helping. I patched revision 4986.

Was at least worth a try. Do you get the same crash as lightbulb reported, or
something else now?
Also, can you try to build with "scons wxgl=true" for a change?

It seems that linux is also picky about LoadStorePaired...
http://pastie.org/802966

Thanks to belegdol for testing out my guess at the same parameters as OSX needs.

Revision 4988M... with the http://pastie.org/802966 patch did not work

Bugbuddy report here

http://pastebin.com/m4dfa27c1

It does work of some sort, since it prevents the initial report from happening. What
you see might be related to the work on GCPad, where yet another X-loop was
introduced (whatever that may be - it got some close-to-negative comments on the
commit the other day)

J4ck i worked your patch into 4897 and it worked again... so heres the patch i made
if someone else wishes to try it... other wise it fixed it on both of my linux computers
so you should really commit that...

also now we just need to find the problem in GCPad(if that's where it lies)...

the patch i just posted helps up until rev. 4948... then when i try to run 4948 i get
what i posted in comment 2 as output...

I honestly don't see how 4948 can cause that, can you give a gdb bt of that crash?

hmm... i just tried compiling 4948 with flavor=debug and ran it in gdb and didn't get
that error... ill keep looking and trying.. sorry but I had tried it at least 5 times
last night and it kept giving me that error...

Ok big never mind... can someone just commit the patch I posted then this issue is
closed because it's working on r4992...

If r4948 (or rather r4961) really is at fault (which it might be due to threading and
things, quote nakee "That how we got into this X event loop mess in the first place..
"), my first patch should fix this for linux. It shouldnt be applied that way tho,
since it will break at least win32 which expects WinMain instead.

This issue was updated by revision r4993.

Disabling LoadStorePaired might affect performance just as Sonics change in r4897 does with OSX.
Leaving this issue open since this is not a fix, just a workaround; this and Issue 2053 might suffer from some problem with Paired instructions altogether.

Please test this with the latest revision and let us know if the segfault still occurs.

skidau: what revision are you talking about cause I'll test whatever

rev. 5367 still requires that I uncomment the
#elif defined(linux)
and
bJITLoadStorePairedOff = true;

otherwise it segfaults

with those enabled games run fine

Theevillightbulb, would you please try turning the flag back to false and change
lines 376, 380

from:

SUB(64, R(RSP), Imm8(0x08));
ADD(64, R(RSP), Imm8(0x08));

to:

SUB(64, R(RSP), Imm8(0x18));
ADD(64, R(RSP), Imm8(0x18));

Got that tip from googling. Let us know if it works.

The file is abi.cpp

The change from comment 25 does not seem to help.

For reference, the workaround was commented out in revision #5157

Ok, thanks for the report. I'll keep on thinking. I might need to install linux x64
again.

Theevillightbulb, I haven't been able to reproduce this problem. For me, Dolphin is
running fine with bJITLoadStorePairedOff commented out in CoreParameters.cpp. I ran
it on Ubuntu 10.04 (x64) running under VirtualBox on a Intel Core2Duo. I tested Wii
Sports and Mario Kart: Double Dash. I used the VideoSoftware plugin, DSP HLE and
Dual Core mode.

Could it be fedora specific?

r5157 gives me this

[ajeets@virus Linux-i686]$ ./dolphin-emu
31:48:159 Source/Core/Common/Src/FileUtil.cpp:92 W[COMMON]: IsDirectory: stat failed on ./user/Wii/title/00000001/00000002/content/:
31:52:029 Source/Core/Core/Src/HW/EXI_DeviceMemoryCard.cpp:102 W[EXI]: No memory card found. Will create new.
31:52:047 Source/Core/Core/Src/HW/EXI_DeviceMemoryCard.cpp:102 W[EXI]: No memory card found. Will create new.
31:52:048 Source/Core/Common/Src/MsgHandler.cpp:53 E[*]: Warning: Executable memory ended up above 2GB!
Killed

Any idea why ?

[ajeets@virus Wii]$ uname -a
Linux virus 2.6.32.12-115.fc12.i686 #1 SMP Fri Apr 30 20:34:53 UTC 2010 i686 i686 i386 GNU/Linux

Issue 3262 has been merged into this issue.

I can confirm that bJITLoadStorePairedOff = true fixes it for Fedora 14 x64.
I guess it's still not fully x64 compatible.

Issue 4073 has been merged into this issue.

Wasn't this supposedly fixed recently?

I'll try it again if you'd like.

...yes

utiba.aj...@gmail.com, if you still have your problem, please open a new issue. It has nothing to do with the problem this issue is about.

I think this should be fixed.

Issue is fixed in Fedora 15 x86_64

still had the Issue in Fedora 14 last time I checked but that has been a long while ago...

Can confirm issue is fixed in Fedora 14 x86_64 - built fine a few weeks ago.