Project

General

Profile

Actions

Emulator Issues #423

closed

(Linux 64-bit) Dolphin crashes when opening a game.

Added by gustakoe over 15 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Hi
Dolphin opens up with no problems whatsoever. The problem comes up when I
try to open a game. At first I double clicked on the executable, tried to
open a game, and it crashed. So I went to the terminal and opened Dolphin
from there; when I tried opening the game, I got another crash, and here
are the lines I got from it:

Open device file: Permission denied
AX ucode chosen, yay!CALL out of range (0x434da000 calls 0x7f80b284c4c0)
(0) : fatal error C9999: *** exception during compilation ***
Cg compiler terminated due to fatal errorE: thread-posix.c: Assertion
'pthread_setspecific(t->key, userdata) == 0' failed at
pulsecore/thread-posix.c:194, function pa_tls_set(). Aborting.
(0) : fatal error C9999: *** exception during compilation ***
Cg compiler terminated due to fatal error

By the way, I saw many, many warnings during compilation.

I'm using:

Dolphin Revision 1621
Ubuntu Intrepid Ibex 64-bit
Pentium D 935
Geforce 7600GS
1GB RAM


Related issues 4 (0 open4 closed)

Has duplicate Emulator - Emulator Issues #977: Game randomly crashes when using dual core and keyboard inputDuplicate

Actions
Has duplicate Emulator - Emulator Issues #1106: Crashes within few seconds of launching gameDuplicate

Actions
Has duplicate Emulator - Emulator Issues #1129: X86_64 Dual Core in linux causes crash at startupDuplicate

Actions
Has duplicate Emulator - Emulator Issues #1151: Linux crashes with dual coreDuplicate

Actions
Actions #1

Updated by chris062689 over 15 years ago

I'm also having this problem,

Dolphin Revision 1623
Ubuntu 8.10 64-bit
E7200 @ 3.7 Ghz
Geforce 9600 GT (Using 178 drivers)
2 GB RAM

Actions #2

Updated by roniesalg over 15 years ago

I also have that problem, but using gdb to backtrace it i get:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x40e10950 (LWP 12855)]
0x000000004024e000 in ?? ()
(gdb) backtrace
#0 0x000000004024e000 in ?? ()
#1 0x00007f094a8028af in VertexLoader::RunVertices (this=0x7f093cad13b0,
vtx_attr_group=0, primitive=3, count=4)
at Source/Core/VideoCommon/Src/VertexLoader.cpp:603
#2 0x00007f094a7e2c5e in VertexLoaderManager::RunVertices (vtx_attr_group=0,
primitive=3, count=4)
at Source/Plugins/Plugin_VideoOGL/Src/VertexLoaderManager.cpp:93
#3 0x00007f094a7f4c59 in Decode ()
at Source/Core/VideoCommon/Src/OpcodeDecoding.cpp:284
#4 0x00007f094a7f4c6b in OpcodeDecoder_Run ()
at Source/Core/VideoCommon/Src/OpcodeDecoding.cpp:315
#5 0x00007f094a80b6d4 in Video_SendFifoData (_uData=0x7f09477e7160 "", len=32)
at Source/Core/VideoCommon/Src/Fifo.cpp:85
#6 0x0000000000477fd5 in CommandProcessor::CatchUpGPU ()
at Source/Core/Core/Src/HW/CommandProcessor.cpp:662
#7 0x0000000000478095 in CommandProcessor::UpdateFifoRegister ()
at Source/Core/Core/Src/HW/CommandProcessor.cpp:706
#8 0x0000000000478483 in CommandProcessor::GatherPipeBursted ()
at Source/Core/Core/Src/HW/CommandProcessor.cpp:627
#9 0x00000000004c8ead in GPFifo::CheckGatherPipe ()
at Source/Core/Core/Src/HW/GPFifo.cpp:91
#10 0x0000000041fb51e8 in ?? ()
#11 0x00000000805410b8 in ?? ()
---Type to continue, or q to quit---
#12 0x0000000040fbe91a in ?? ()
#13 0x00007fff5e4e2760 in ?? ()
#14 0x00007fff5e4e2760 in ?? ()
#15 0x0000000000000000 in ?? ()

Then if I go the the frame 1 I got:
#1 0x00007f094a8028af in VertexLoader::RunVertices (this=0x7f093cad13b0,
vtx_attr_group=0, primitive=3, count=4)
at Source/Core/VideoCommon/Src/VertexLoader.cpp:603
603 ((void ()())(void)m_compiledCode)();

In that place I have this code:
#ifdef USE_JIT
if (remainingVerts > 0) {
loop_counter = remainingVerts;
((void ()())(void)m_compiledCode)();
}
#else
for (int s = 0; s < remainingVerts; s++)
{
tcIndex = 0;
colIndex = 0;
s_texmtxwrite = s_texmtxread = 0;
for (int i = 0; i < m_numPipelineStages; i++)
m_PipelineStagesi;
PRIM_LOG("\n");
}
#endif

Then finding in that same file I found on VertexLoader::CompileVertexTranslator():

#ifdef USE_JIT
if (m_compiledCode)
PanicAlert("trying to recompile a vtx translator");

m_compiledCode = GetCodePtr();
ABI_EmitPrologue(4);

// Start loop here
const u8 *loop_start = GetCodePtr();

// Reset component counters if present in vertex format only.
if (m_VtxDesc.Tex0Coord || m_VtxDesc.Tex1Coord || m_VtxDesc.Tex2Coord ||

m_VtxDesc.Tex3Coord ||
m_VtxDesc.Tex4Coord || m_VtxDesc.Tex5Coord || m_VtxDesc.Tex6Coord ||
m_VtxDesc.Tex7Coord) {
MOV(32, M(&tcIndex), Imm32(0));
}
if (m_VtxDesc.Color0 || m_VtxDesc.Color1) {
MOV(32, M(&colIndex), Imm32(0));
}
if (m_VtxDesc.Tex0MatIdx || m_VtxDesc.Tex1MatIdx || m_VtxDesc.Tex2MatIdx ||
m_VtxDesc.Tex3MatIdx ||
m_VtxDesc.Tex4MatIdx || m_VtxDesc.Tex5MatIdx || m_VtxDesc.Tex6MatIdx ||
m_VtxDesc.Tex7MatIdx) {
MOV(32, M(&s_texmtxwrite), Imm32(0));
MOV(32, M(&s_texmtxread), Imm32(0));
}
#endif

Its looks like the code was compiled for an x86_32 in a x86_64 architecture, and that
cause this problem.

Actions #3

Updated by magumagu9 over 15 years ago

Does the following patch work?

Index: Source/Plugins/Plugin_VideoOGL/Src/VertexLoader.cpp

--- Source/Plugins/Plugin_VideoOGL/Src/VertexLoader.cpp (revision 1660)
+++ Source/Plugins/Plugin_VideoOGL/Src/VertexLoader.cpp (working copy)
@@ -484,7 +484,12 @@
void VertexLoader::WriteCall(TPipelineFunction func)
{
#ifdef USE_JIT
+#ifdef _M_X64

  • MOV(64, R(RAX), Imm64((u64)func));
  • CALLptr(R(RAX));
    +#else
    CALL((void*)func);
    +#endif
    #else
    m_PipelineStages[m_numPipelineStages++] = func;
    #endif
Actions #4

Updated by gustakoe over 15 years ago

Hi
I would really love to experiment with these patches, though I have no experience on
how to do it. I'm new to all of these. Basically my first compile ever was when I
first compiled Dolphin (about a month ago). Since then I've always compiled it on
Ubuntu 8.10 32-bit and works pretty nice. Now I would like to try it on 64-bit
wishing for a speed increase, but this issue comes up with every single revision.

Actions #5

Updated by BMcDorman over 15 years ago

vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x29 0xC6 0x66 0xF
==22782== valgrind: Unrecognised instruction at address 0x1B18112A.
==22782== Your program just tried to execute an instruction that Valgrind
==22782== did not recognise. There are two possible reasons for this.
==22782== 1. Your program has a bug and erroneously jumped to a non-code
==22782== location. If you are running Memcheck and you just saw a
==22782== warning about a bad jump, it's probably your program's fault.
==22782== 2. The instruction is legitimate but Valgrind doesn't handle it,
==22782== i.e. it's Valgrind's fault. If you think this is the case or
==22782== you are not sure, please let us know and we'll try to fix it.
==22782== Either way, Valgrind will now raise a SIGILL signal which will
==22782== probably kill your program.
==22782==
==22782== Process terminating with default action of signal 4 (SIGILL)
==22782== Illegal opcode at address 0x1B18112A
==22782== at 0x1B18112A: ???
==22782== by 0xFFF: ???
==22782== by 0xFFF: ???

Seems as though the problem can trace its roots in x64Emitter. GetCodePtr() returns
an illegal code that is then run.

Actions #6

Updated by BMcDorman over 15 years ago

As stated in the x64Emitter.h file, the opengl32's address space is way above what is
accessible. Could this address space be at a different location on x64 linux?

Actions #7

Updated by BMcDorman over 15 years ago

it is still broken..... :\

Actions #8

Updated by gustakoe over 15 years ago

Hey
I just tried the patch file magumagu9 submitted, and this is the output:

patching file Source/Core/VideoCommon/Src/VertexLoader.cpp
Hunk #1 FAILED at 484.
1 out of 1 hunk FAILED -- saving rejects to file
Source/Core/VideoCommon/Src/VertexLoader.cpp.rej

Btw, I had to figure out where VertexLoader.cpp went because it is not inside the
directory magumagu9 said it was in anymore.

Actions #9

Updated by shallwebr over 15 years ago

I try the patch but not work, the same error here in ubuntu x64 :(

Actions #10

Updated by shallwebr over 15 years ago

is it the error?

shallwe@shallwe-desktop:~/emulador/dolphin$ ./Dolphin
JAC ucode chosenCALL out of range (0x42ee0014 calls 0x7f95315f4010)
CALL out of range (0x42ee0019 calls 0x7f95315f0fc0)
CALL out of range (0x42ee001e calls 0x7f95315f5080)
(0) : fatal error C9999: *** exception during compilation ***
Cg compiler terminated due to fatal error(0) : fatal error C9999: *** exception
during compilation ***
Cg compiler terminated due to fatal errorshallwe@shallwe-desktop:~/emulador/dolphin$

Actions #11

Updated by magumagu9 over 15 years ago

Could someone run gdb, and paste a backtrace into this bug? The commands in gdb, in case anyone
doesn't know/remember them:
break x64Emitter.cpp:344
run
bt

Actions #12

Updated by BMcDorman over 15 years ago

#0 Gen::XEmitter::CALL (this=0x7fffe0c17668, fnptr=0x7fffdec4b9b9) at
Source/Core/Common/Src/x64Emitter.cpp:344
#1 0x00007fffdec44ff5 in VertexLoader::WriteCall (this=0x7fffe0c17660,
func=0x7fffdec4b9b9 <Pos_ReadDirect_UShort()>) at
Source/Core/VideoCommon/Src/VertexLoader.cpp:483
#2 0x00007fffdec45abb in VertexLoader::CompileVertexTranslator (this=0x7fffe0c17660)
at Source/Core/VideoCommon/Src/VertexLoader.cpp:216
#3 0x00007fffdec47171 in VertexLoader (this=0x7fffe0c17660,
vtx_desc=@0x7fffdee7e828, vtx_attr=@0x7fffdee7e840) at
Source/Core/VideoCommon/Src/VertexLoader.cpp:127
#4 0x00007fffdec250a7 in RefreshLoader (vtx_attr_group=0) at
Source/Plugins/Plugin_VideoOGL/Src/VertexLoaderManager.cpp:79
#5 0x00007fffdec2512e in VertexLoaderManager::GetVertexSize (vtx_attr_group=0) at
Source/Plugins/Plugin_VideoOGL/Src/VertexLoaderManager.cpp:98
#6 0x00007fffdec36aa0 in FifoCommandRunnable () at
Source/Core/VideoCommon/Src/OpcodeDecoding.cpp:148
#7 0x00007fffdec36f50 in OpcodeDecoder_Run () at
Source/Core/VideoCommon/Src/OpcodeDecoding.cpp:312
#8 0x00007fffdec4dc2c in Video_SendFifoData (_uData=0x7fffdb07ad60 "\202A \200",
len=32) at Source/Core/VideoCommon/Src/Fifo.cpp:85
#9 0x0000000000478973 in CommandProcessor::CatchUpGPU () at
Source/Core/Core/Src/HW/CommandProcessor.cpp:662
#10 0x0000000000478a4f in CommandProcessor::UpdateFifoRegister () at
Source/Core/Core/Src/HW/CommandProcessor.cpp:706
#11 0x000000000047968b in CommandProcessor::GatherPipeBursted () at
Source/Core/Core/Src/HW/CommandProcessor.cpp:627
#12 0x00000000004d5bf6 in GPFifo::CheckGatherPipe () at
Source/Core/Core/Src/HW/GPFifo.cpp:91
#13 0x00000000004d5ceb in GPFifo::Write8 (_iValue=97 'a', _iAddress=3422584832) at
Source/Core/Core/Src/HW/GPFifo.cpp:100
#14 0x000000000047efd7 in Memory::Write_U8 (_Data=97 'a', _Address=3422584832) at
Source/Core/Core/Src/HW/Memmap.cpp:861
#15 0x00000000400021a0 in ?? ()
#16 0x0000000080367790 in ?? ()
#17 0x00000000402d2a4b in ?? ()
#18 0x0000000000001000 in ?? ()
#19 0x0000000000001000 in ?? ()
#20 0x0000000000000000 in ?? ()

There you are.. your instructions verbatim

Actions #13

Updated by Sonicadvance1 over 15 years ago

This was due to revision 1594.
If you go to the VertexLoader.cpp file and comment out the #define USE_JIT
so that vertexloader doesn't JIT, it will run like it used to, Going to guess a
little bit slower though.

Actions #14

Updated by BMcDorman over 15 years ago

I have actually tried this sonic, with limited results... No crash, but no video :/

Actions #15

Updated by BMcDorman over 15 years ago

Is anyone still experiencing this problem like me?

Actions #16

Updated by tinctorius over 15 years ago

It's still there (r1795). With magumagu9's patch, still Dolphin chokes on
m_compiledCode. I think I have an idea why this happens though.

This is what was in my m_compiledCode once:

00: c7 05 9e 16 7a 5f 00 00 00 00 movl $0x0,0x5f7a169e(%rip) # 0x5f7a16a8
0a: c7 05 98 16 7a 5f 00 00 00 00 movl $0x0,0x5f7a1698(%rip) # 0x5f7a16ac
14: 48 b8 fe df f8 9f a5 7f 00 00 mov $0x7fa59ff8dffe,%rax
1e: ff d0 callq *%rax
20: 48 b8 e8 b5 f8 9f a5 7f 00 00 mov $0x7fa59ff8b5e8,%rax
2a: ff d0 callq *%rax
2c: 48 b8 22 ef f8 9f a5 7f 00 00 mov $0x7fa59ff8ef22,%rax
36: ff d0 callq *%rax
38: 83 2d c1 16 7a 5f 01 subl $0x1,0x5f7a16c1(%rip) # 0x5f7a1700
3f: 0f 85 bb ff ff ff jne 0x0
45: c3 retq

In a 64-bit Linux, the symbol it's trying to access using the instructions on address
0x0, 0x10 and 0x38 seems to be loop_counter (in
VertexLoader::CompileVertexTranslator). This variable is defined in the plugin as a
static variable. I can't determine what it's address is, but my naive guess is that
it's somewhere in the shared object's .bss section. Since 0x7fa59ff8ef22 is an
address in it's .text, it's .bss is probably relatively near to it.

However, m_compiledCode resides in dynamically allocated memory, which is somewhere
like 0x00000000414b5000. That's nowhere near VideoOGL's .bss, and addressing relative
to the instruction pointer (%rip) can't quite cover that distance. Or so I guess.

Solution: if possible (think about concurrence), put the loop_counter in the first
few bytes of m_compiledCode, so that it's pretty much guaranteed that the relative
addressing works, and start writing (and executing!) the compiled code just after
that piece of data.

Actions #17

Updated by tinctorius over 15 years ago

Wait, disregard that 'solution'. That won't work, since the segmentation fault
actually happens when the compiled code attempts to access variables defined between
line 52 and 68 of VertexLoader.cpp. So to complete that solution, you'll have to move
those variables too. Even worse: if you move them, you'll need to compile all
functions you use into that code blob, and all the data they use, etcetera, etcetera,
etcetera.

Another idea may be saving the code pointer, statically allocating the code blob
(instead of using AllocCodeSpace) and then restoring the original code pointer. That
will cause the code blob to reside in the .bss section of the plugin (or so I think).
I don't know wether that guarantees a 'safe' distance, but it is a start.

Actions #19

Updated by tinctorius over 15 years ago

Fixed. Applying the patch from comment number 4, introducing a new emitter I called
Write[GS]etVariable (which does an indirect MOV if you're using x86_64) and also
SUB'ing loop_counter using indirect addressing when on x86_64, I get no crashes anymore.

Patch: http://www.dolphin-emu.com/forum/viewthread.php?thread_id=288

Actions #20

Updated by magumagu9 over 15 years ago

I don't feel comfortable reviewing 64-bit changes because I don't have a computer to test with.

Actions #21

Updated by tinctorius over 15 years ago

You can at least test it doesn't destroy functionality on 32-bit systems ;)

Actions #22

Updated by tinctorius over 15 years ago

Is this patch being reviewed? It works like a charm for me, and I'd like to have it
in trunk...

Actions #23

Updated by shallwebr over 15 years ago

Yes this patch http://www.dolphin-emu.com/forum/viewthread.php?thread_id=288
Work for me.

Tanks tinctorius :D

Actions #24

Updated by XTra.KrazzY over 15 years ago

  • Status changed from New to Fixed
Actions #25

Updated by diegovazquez over 15 years ago

This problem is not Fixed.

Dolphin Revision 2981
Ubuntu 9.04 64-bit
Geforce 8600 GT (Using 180.44 drivers)
1 GB RAM

I can't get this patch http://www.dolphin-emu.com/forum/viewthread.php?thread_id=288

Actions #26

Updated by matthew.hung about 15 years ago

could someone pls post a new link for that patch file pls?
thx

Actions #27

Updated by nakeee about 15 years ago

  • Status changed from Fixed to Accepted

XK how is this marked as fixed if the patch not in trunk?
I also want to see that patch..

Actions #28

Updated by matthew.hung about 15 years ago

handler instance (nil)
30:11:815 N: BOOT Loading Settings from ./User/Config/Dolphin.ini
30:11:858 N: BOOT Starting application
30:11:858 N: BOOT Loading Settings from ./User/Config/Dolphin.ini
30:11:976 W: COMMON IsDirectory: stat failed on
./USER/WII/TITLE/00000001/00000002/CONTENT:
30:15:556 N: Video glX-Version 1.2

-----------------end of error message----------------------
I am using svn r 3275
still got segmentation fault
hope this helps
thx

Actions #29

Updated by tinctorius about 15 years ago

I think the link is dead and there's no way to revive the patch without rewriting it
(unless someone has it laying around). According to the forums, I only have "one
post", which is a different patch I posted once.

But see c21 for what the patch actually is; it's not really that hard to implement it
if you know your way around the JIT code.

Actions #30

Updated by tinctorius about 15 years ago

Found it in /home/tinctorius/DUMP/dump. Say yay for cleaning up your home folder.

Actions #31

Updated by Morgan.Torvolt about 15 years ago

I just tried to apply this patch, but it fails. Seems that it is already in SVN.
This still crashes for me. Here is a log from starting with HLE first and LLE
second, last one hangs, so I press stop, and that is when it segfaults. I guess the
LLE is not so interesting maybe, but none of them works.

http://pastebin.com/m12dd3bd

Actions #32

Updated by hrydgard about 15 years ago

Looks like your current crash is a new problem unrelated to this issue. Now the Cg
compiler is crashing. Do you have the latest version of Cg installed? Do you have old
graphics drivers?

Actions #33

Updated by Morgan.Torvolt about 15 years ago

I just installed the newest nvidia drivers on request from nakee on IRC. This made
no difference. Regarding Cg, I don't know how to check that, but it is the standard
nvidia-cg-toolkit package in ubuntu 9.04. The documentation changelog sais 2.0.0015.

Actions #34

Updated by tinctorius about 15 years ago

The patch was indeed already checked in. This particular JIT issue (I mean the one
described in comment 3 and on, not necessarily the one in comment 1) should already
be fixed in trunk a looong time.

Morgan.Torvolt's problem (and probably gustakoe's, in comment 1) looks like an
unrelated issue.

Actions #35

Updated by Morgan.Torvolt about 15 years ago

Right. So a different bug than the one reported got fixed? In that case, is there
anything I can do to help fix this?

Actions #36

Updated by XTra.KrazzY about 15 years ago

I dunno, it seemed to really work on my 64-bit SuSE machine

Actions #37

Updated by XTra.KrazzY about 15 years ago

Issue 1129 has been merged into this issue.

Actions #38

Updated by XTra.KrazzY about 15 years ago

Issue 1106 has been merged into this issue.

Actions #39

Updated by XTra.KrazzY about 15 years ago

Issue 977 has been merged into this issue.

Actions #40

Updated by diegomzz about 15 years ago

This is still a problem on the last revision.

Actions #41

Updated by XTra.KrazzY almost 15 years ago

Issue 1151 has been merged into this issue.

Actions #42

Updated by arablizzard2413 almost 15 years ago

Is this being worked on at all? The crash only happens when dual core is enabled.

Actions #43

Updated by diegomzz almost 15 years ago

Dual core AND padsimple. Works ok with njoy and dual core.

Actions #44

Updated by samurailink3 almost 15 years ago

Getting error: W[CONSOLE]: PluginInfo: Plugins/libPlugin_VideoOGL.so is not a valid
Dolphin plugin. Ignoring.

On Linux 64-bit
Build: 4307

OGL Video plugin isn't properly recognized and is not show in the list.

Actions #45

Updated by nakeee over 14 years ago

I think this bug is solved.
Does anyone disagree?

Actions #46

Updated by nakeee over 14 years ago

  • Status changed from Accepted to Fixed

marking as fixed, if they is another linux crash please put it in a new issue.

Actions #47

Updated by individuo7 about 14 years ago

for [Comment 46 by samurailink3, Sep 20, 2009] intall nvidia-cg-toolkit on ubuntu

Actions

Also available in: Atom PDF