Citra: Zelda Ocarina of Time crashing when the deku tree is talking.

[Ncapron]

When you leave the deku tree after beating Ghoma you got the heart, that gives you a 4th heart for your HP. And then you go back outside the tree and he says something like "do you want me to tell you more?" you have the choice between yes or no. and Then the game crash with this on the console.

Btw : I'm playing on mac with Nightly Build - 55c91ae version

''

ped buffers are unimplemented at the moment
[ 125.866441] Audio.DSP audio_core/hle/source.cpp:DequeueBuffer:259: Looped buffers are unimplemented at the moment
[ 126.094656] Audio.DSP audio_core/hle/source.cpp:DequeueBuffer:259: Looped buffers are unimplemented at the moment
[ 126.628569] Audio.DSP audio_core/hle/source.cpp:DequeueBuffer:259: Looped buffers are unimplemented at the moment
[ 126.700078] Audio.DSP audio_core/hle/source.cpp:DequeueBuffer:259: Looped buffers are unimplemented at the moment
[ 126.894703] Audio.DSP audio_core/hle/source.cpp:DequeueBuffer:259: Looped buffers are unimplemented at the moment
[ 127.785783] Debug video_core/renderer_opengl/gl_rasterizer.cpp:operator():1084: Assertion Failed!
Uniform block size did not match! Got 0, expected 960
Trace/BPT trap: 5
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
Deleting expired sessions...none found.

[Opération terminée]
''

[Ncapron]

https://www.dropbox.com/s/39s7hziampuqqel/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.15.png?dl=0

https://www.dropbox.com/s/h0zb65epl9721zf/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.21.png?dl=0

https://www.dropbox.com/s/cklma7g673gjwly/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.28.png?dl=0

https://www.dropbox.com/s/zs7ket7tpeu5bnu/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.35.png?dl=0

https://www.dropbox.com/s/9hhpkddp5qr50cb/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.42.png?dl=0

https://www.dropbox.com/s/jqh3acq6dz7tams/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.47.png?dl=0

[JamesBlandford]

ZIP the "0030700" folder for me, there are some saved replay files in there inside the "000000001"

[Ncapron]

French version savefile: 00030700.zip

i saved the game when i killed Ghoma so you just have to go the the room and use the blue portal and talk with the deku tree

but when you'll talk to the tree, you just have to press "A" again and again and he'll ask if you want to know more ?
-> yes (oui)
->no (non)

and whatever the choice he will say "ok there is a curse" and it crashed

Posts merged by JayFoxRox

[JamesBlandford]

i've been unable to test your savefile, tried both USA region ROM and EU region ROM both don't have the right save ID
could you provide futher details on what version of the ROM you are using is?

[PPLToast]

The titleid 00030700 from Ncapron is for Mario Kart 7 and not OoT3D. He might be checking the wrong save folders. Also prasoc, you said your OoT3D was "european english", but the id you posted (00033500) is for the american version??

[JamesBlandford]

I have got EUR 00033600 too, just waiting for Ncapron to provide the real save now then :)

[Ncapron]

I just have the one that I've sent :/
you can see the path with those pictures

https://www.dropbox.com/s/39s7hziampuqqel/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.15.png?dl=0

https://www.dropbox.com/s/h0zb65epl9721zf/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.21.png?dl=0

https://www.dropbox.com/s/cklma7g673gjwly/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.28.png?dl=0

https://www.dropbox.com/s/zs7ket7tpeu5bnu/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.35.png?dl=0

https://www.dropbox.com/s/9hhpkddp5qr50cb/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.42.png?dl=0

https://www.dropbox.com/s/jqh3acq6dz7tams/Capture%20d%27%C3%A9cran%202017-01-18%2020.49.47.png?dl=0

[ghost]

This must be Mac related because I've been able to continue and progress after this event on Windows 10 on a recent bleeding-edge build just fine (Ocarina of Time 3D European version) and I'm heading up to Death Mountain now in the game.

[fabikw]

It's not a mac issue. It happens to me in Win 7.

[fabikw]

Couldn't upload, so here's a link:
OoT Save Folder

Just go through the dungeon (drop through hole, climb block to the left, drop through hole, enter door) to the boss room (already cleared) and get into the portal, try to listen to story of Deku Tree

[RavenHome1]

same here, windows 7 the emulator crashed

[Schplee]

This may be a hardware issue, because the most recent Nightly (e10b11a) and BE-202 do not crash after/while talking with the Deku tree. I used @fabikw's save file, tested on Windows 10.

[fabikw]

Haven't tried since BE 194 and the nightly from that day. I'll try again with the new version.

[fabikw]

I tried BE 202, disabled Shader JIT and still got the same crash.
@Schplee did you go through the dungeon to the end to have the Deku Tree cutscene? This cutscene is not triggered by going out of the dungeon through the entrance and talking with the tree.

[FernandoS27]

Shader-JIT is unrelated to that. The 3ds emulated shaders are run on the cpu. Those are the OpenGL shaders giving troubles due to a mismatch between what we are inserting into them and what they expect.

A simple solution is to disable the hardware renderer only on that part.

[Schplee]

@fabikw I know how the cutscene is triggered. Yes, I went through the blue portal in the dungeon where you defeat Gohma. In both the Nightly and the Bleeding Edge, I was able to view the cutscene without a single issue. I am going to perform a couple tests and edit this post with anything I've found.

I did a fresh install of both Bleeding Edge-204 and the most recent Nightly (1bf449d). This meant creating a blank user folder in the installation directory, and not using the system_font or the system_archives (Nand folder). Everything was generated by Citra. I then used @fabikw's save file in each build, separately. Neither builds crashed while proceeding with the Deku Tree cutscene. I am on Windows 10.

Bleeding Edge:

Nightly (1bf449d):

It must be user-specific issues, maybe an issue with the user's hardware. Can someone who is still experiencing this issue upload a log file from either the most recent Nightly/BE build? Here's a guide to follow if you don't know how to get the log file.

How to Get Log File

[FernandoS27]

hmn, could you get us your gpu specs using gpu-z ?

[fabikw]

This is a dropbox link to my log. Too big for pastebin. I redacted the top info, but it stops at 2 sec. (I have my log filter set to the default "*:Info").

When running normally, I usually have the log-filter set to "*:Critical" and I get something like:

[ 127.785783] Debug video_core/renderer_opengl/gl_rasterizer.cpp:operator():1084: Assertion Failed!
Uniform block size did not match! Got <some number>, expected 960

My laptop has two gpus, An integrated one and a regular one. Don't know how to check which one citra is using.

[Schplee]

@fabikw The link to your log file says the file is no longer there. Both of your GPU's support OpenGL 4+ so I don't see an issue with compatibility. I'd still like to be able to see your log file though.

[fabikw]

I reuploaded the file, but it stops at 2 seconds. I can do another one with a different log filter later.

[FernandoS27]

hmn, could anyone else having this issue post their gpu specs? I need to check if it is AMD related.

[TTFH]

On nVidia (tested on GTX 650 and GTX 1080) the crash doesn't happen but in Intel it happen 100% of the time (at least on Celeron N2830)

[fabikw]

I got past it on an nVidia card.

On Feb 16, 2017 18:14, "TTFH" [e-mail] wrote:

On nVidia (tested on GTX 650 and GTX 1080) the crash doesn't happen but in
Intel it happen 100% of the time (at least on Celeron N2830)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/citra-emu/citra/issues/2447#issuecomment-280495021,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATjVdqZ6wA1-e-lX5jp31IIwPv5okBZJks5rdNhqgaJpZM4Ll5xv
.

[JayFoxRox]

Stop these useless lengthy discussions (or even worse: speculation) please. If anybody is able to reproduce the issue they should upload a proper trace of what happens or a good dump of the last compiled shader.

We don't care if anybody found a savegame or temporarily switched to another GPU or s/w rendering to work around the issue. We should care about fixing the issue and getting data to work with. So please provide an apitrace trace file. I've followed this issue for months and nobody seems to be able to produce a good trace / description.

//Edit: I just realized that TTFH posted a good dump a month ago. Oops!

[TTFH]

Here is a apitrace dump before the crash (just the last 600 lines).

log.txt

[JayFoxRox]

I've tried to clean up the thread a little. @citra-emu/maintainers please shut down disucssions earlier next time and refer people to the forums. If people are not skilled enough to upload save files or debug issues they should not post in these issues.

---

Thanks a lot @TTFH , sorry again, I didn't see your earlier post (due to all the other noise).
I'm not sure where you got the idea about tex[3] and lut[6] being problematic.
The problem is pretty obvious: shader_data is optimized out as it's not used in the shader:

1327 glUseProgram(program = 180)
1328 glGetUniformLocation(program = 180, name = "tex[0]") = -1
1329 glGetUniformLocation(program = 180, name = "tex[1]") = -1
1330 glGetUniformLocation(program = 180, name = "tex[2]") = -1
1331 glGetUniformLocation(program = 180, name = "lut[0]") = -1
1332 glGetUniformLocation(program = 180, name = "lut[1]") = -1
1333 glGetUniformLocation(program = 180, name = "lut[2]") = -1
1334 glGetUniformLocation(program = 180, name = "lut[3]") = -1
1335 glGetUniformLocation(program = 180, name = "lut[4]") = -1
1336 glGetUniformLocation(program = 180, name = "lut[5]") = -1
1337 glGetUniformLocation(program = 180, name = "fog_lut") = -1
1338 glGetUniformBlockIndex(program = 180, uniformBlockName = "shader_data") = 4294967295
1339 glGetActiveUniformBlockiv(program = 180, uniformBlockIndex = 4294967295, pname = GL_UNIFORM_BLOCK_DATA_SIZE, params = 0x1c1fe0e0)

In line 1338 you can see that querying the shader_data variable fails and returns -1 (4294967295). Querying the active uniform block with index -1 does fail and return a broken size.

There are 2 steps necessary to fix this issue:

1. Be more careful when querying uniform blocks by checking if their index is even valid (so anything but GL_INVALID_INDEX). This would fix the issue and improve code quality.
2. Find out why the shader is even compiled. I can't think of a realistic situation where you'd want to make a draw call and abort writing any pixels (except for pixel counting / early-out z-tests which we don't support yet. Maybe stencil?). It looks to me like we should optimize out the entire draw-call. It's also possible that something else goes wrong and causes this bizarre rendering state (even if it doesn't crash, it still means wasted time on a draw call).

[jroweboy]

Fixed by #2581

[RavenHome1]

can confirm that it is working now