Screen freezing

[kochon]

Since latest release, npc text won’t scroll and sub menus often freeze for example the healers menu doesn’t appear but still works if you press a the conversation menu appears.

Also while in dungeon the screen seems to freeze every other second while the audio isnt affected.

Also the debug text in the bottom screen doesnt appear anymore

Thats on new 3ds xl

[MrHuu]

Thanks for letting me know. I'm currently not sure what the exact issue would be.

This build doesn't seem to have the issue's you described: DevilutionX_CIA.zip It's an earlier build, without some of the upstream changes included in the released build.

The console on the bottom screen is disabled for the released build. Which is intentional.

[kochon]

Thanks for letting me know. I'm currently not sure what the exact issue would be.

This build doesn't seem to have the issue's you described: DevilutionX_CIA.zip It's an earlier build, without some of the upstream changes included in the released build.

The console on the bottom screen is disabled for the released build. Which is intentional.

This build works flawlessly so far on my device. Thank you so much, this will help tremendously during these confined times. Let me know if I can further collaborate or test anything else.

[MrHuu]

The released build wasn't optimized during compilation. Resulting in the performance experienced on hardware. Citra doesn't show this issue.

A new build is available, which addresses the issue. It also uncovered an other related issue with the game crashing upon entering lvl 13. Where, conveniently, i'm currently at myself.

[AJenbo]

@MrHuu is the build unstable at O3 (default for other builds). Have you been able to narrow down code is causing issues on O2?

[MrHuu]

Performance seems similar for -O2 and -O3. I should probably use the BINARY_RELEASE for this.

This was actually the first consistent crash i have encountered. I've been playing with -O2 optimized builds myself. But in this case while trying to track down the issue, noticed the 'segmentation fault' not happening without optimization.

I haven't been able to track down the exact cause of the crash, other than the quick fix applied here: https://github.com/MrHuu/devilutionX-3ds/commit/0e7b2408b33362d8b4477b2b72098061ce4764d1 Optimizing, -O2 or -O3, the currently excluded code results in a consistent segfault in function DRLG_L4FTVR reported by GDB. Occurring upon loading lvl 13.

[AJenbo]

Ok, I can see that function has the potential to have OOB issues. Could you share a save game that will trigger it? Then I might be able to fix it.

[MrHuu]

Here's a save right in front of lvl13 entrance - single_0.sv_lvl12.zip

Hmm, with the changes reverted compiling as BINARY_RELEASE which defines -O3, the loading of lvl13 seems fine. Performance issues, like the 'screen freezing' do re-occur.

[AJenbo]

Hmm ASAN doesn't spot anything and I even checked all read/write in DRLG_L4FTVR, and DRLG_L4FTVR, and none of them are OOB. The function itself also appears trivial with no exotic code. About the only special thing is that it does have some recussion, at the deepest point it is 520 calls on top of each other. I'm wondering if that is a problem for the 3DS?

[MrHuu]

Thank you @AJenbo, much appreciated.

After recursing 360 times, the issue occurs. If the maximum depth would be the issue, shouldn't -O0 also be affected?

Here's a full backtrace of the segfault. backtrace.log Build with -O2, and ran on a new3ds.

Citra doesn't seem affected by this.

Also, my previous statement was incorrect, -O3 does have the same issue as -O2.

[AJenbo]

Ok, it looks like the issue is simply a stack overflow. It looks like you have only set 256kb aside for the stack, this is probably way too little. Try at least 512kb (Windows appears to have a default of 1mb)

https://github.com/MrHuu/devilutionX-3ds/blob/3DS/Packaging/ctr/template.rsf#L181

I'm going to guess that at O3 it use larger frames than at O0 for some reason. Or maybe it just happens to align in a way that doesn't cause a hard crash.

[MrHuu]

I've been trying to increase the stacksize, as suggested.

The default size set by libctru is 32kb. This can be changed by defining __stacksize__. Like this:

const unsigned int __stacksize__ = 4 * 1024 * 1024; // 4MB

This should override the default on initialization.

I'm not really sure how 'StackSize' defined in the .rsf affects the actual size used. Which definition gets prioritized.

I've been testing different builds with either one of the methods or both, increasing the StackSize to 512kb, 1mb, 4mb. Apparently, without effect at first glance. The same issue remains.

I'll have to do more research on this part, before fully understanding what's actually happening.

[MrHuu]

I'll close this, since the initial issue is solved. Feel free to re-open or create a new issue when needed.