Crashes on the latest commit, and happens on bleeding edge too.
Shader JIT: On
CPU JIT: On
Hardware Rendering: On
This can be reproduced in many areas, like Waluigi Pinball after the race ends. I got this crash shortly after beginning the second section of Rainbow Road.
"Call Stack" more useful then "Output" window
Alright, I'll try doing the crash again with Call Stack.

Here's the call stack.
Can you try with either JIT disabled to see which one is causing the issue?
Happens with both JITs disabled.
could you get the call stack again with both disabled?
I took some time today to look into this issue. It seems to be a problem with our source register look up in the shader code. I played through MK7 on Maple Treeway in Release with the CPU JIT on and the Shader JIT off and arrived at the following stack trace http://i.imgur.com/XBKp3GX.jpg (spot in the code: https://github.com/citra-emu/citra/blob/master/src/video_core/shader/shader_interpreter.cpp#L152 ) Notice in the picture that the src1_ variable is clearly invalid, while the src2_ seems to be valid. For testing, I also ran it in Debug mode and it did not crash, but it took around 20 minutes to get there, so I decided to not test that anymore.
I went a little deeper and found out that its actually pointing to the address of the uniform registers + some excessively large constant. To help me debug this, I logged any value of source_reg.GetIndex() that wasn't in the range 0-95 (the size of the uniform's f array) and learned that the numbers coming in are hardly bounded to the size of the array at all! In my quick glance at the logs, I saw loads of values ranging from -6000 all the way to +6000 ish, but none of those caused crashes, because I assume that they are valid memory that citra has access too. Citra only crashed when it attempted to access index 134388 which is obviously way out of the array and caused the segfault when it was later accessed.
As an unacceptable workaround, I added a mod 96 to the shader interpreter, and that fixed the issue. I don't know how to proceed to figure out what the hardware does in this scenario right now, so I'm kinda stuck here.
To help a future person debug this issue, I'm uploading my save of the game https://drive.google.com/file/d/0B8hW8rreabPRVWJSU1paYVdjM00/view?usp=sharing To replicate the issue, just go to Time Trial -> Choose anyone -> Maple Treeway -> drive until it crashes after landing the first large jump.
hmn, could you dump the crashing shader and find the crashing instruction ? it could be a problem with al ax ay being out of bounds.
MK7 seems to write weird negative values to the ay register at the start of one of its shaders.
The first negative value it writes is ay = -198. The -198 comes from the float uniform c5.w, which comes from some matrix multiplication code in ARM.
I'm not sure if this is a bug in our VFP emulation yet, but i don't think it's a problem with the shader interpreter itself.
After some testing, it seems using an out of bounds index when addressing an uniform will freeze/crash the hardware GPU, this hints at the problem being in our emulated CPU.
If it helps anyone else debug this, some of the shaders that trigger this crash can be identified by the lower 32 bits of their cache_key hash codes within video_core/shader_jit_x64.cpp:
0x103de4ff, 0xcf72173f, 0xeef75286, 0x450d991d
But as diagnosed above, it's just a symptom of a much deeper issue that I've also been unable to back into. These shaders don't crash all of the time, but they seem to all be associated with effects on the kart's wheels and may crash when landing from an aerial jump where your wing deploys.
I was able to make MK7 playable with shader JIT on by bypassing these specific shaders within JitX64Engine::Run() (I extended ShaderSetup to store the hash key computed within JitX64Engine::SetupBatch so I could check it within Run) It's a sick hack, but it works for now. Usually.
On latest Canary Build. Maple Treeway issue still persist.
Can confirm the new GPU shaders seem to fix this issue. MK7 works like a champ now.
Someone please test this with Hardware Shader on vs off. If both options does not cause any crash, this issue can be close.
Most helpful comment
I took some time today to look into this issue. It seems to be a problem with our source register look up in the shader code. I played through MK7 on Maple Treeway in Release with the CPU JIT on and the Shader JIT off and arrived at the following stack trace http://i.imgur.com/XBKp3GX.jpg (spot in the code: https://github.com/citra-emu/citra/blob/master/src/video_core/shader/shader_interpreter.cpp#L152 ) Notice in the picture that the
src1_variable is clearly invalid, while thesrc2_seems to be valid. For testing, I also ran it in Debug mode and it did not crash, but it took around 20 minutes to get there, so I decided to not test that anymore.I went a little deeper and found out that its actually pointing to the address of the uniform registers + some excessively large constant. To help me debug this, I logged any value of
source_reg.GetIndex()that wasn't in the range 0-95 (the size of the uniform'sfarray) and learned that the numbers coming in are hardly bounded to the size of the array at all! In my quick glance at the logs, I saw loads of values ranging from -6000 all the way to +6000 ish, but none of those caused crashes, because I assume that they are valid memory that citra has access too. Citra only crashed when it attempted to access index 134388 which is obviously way out of the array and caused the segfault when it was later accessed.As an unacceptable workaround, I added a mod 96 to the shader interpreter, and that fixed the issue. I don't know how to proceed to figure out what the hardware does in this scenario right now, so I'm kinda stuck here.
To help a future person debug this issue, I'm uploading my save of the game https://drive.google.com/file/d/0B8hW8rreabPRVWJSU1paYVdjM00/view?usp=sharing To replicate the issue, just go to Time Trial -> Choose anyone -> Maple Treeway -> drive until it crashes after landing the first large jump.