[ARM64EC/Labyrinth of Touhou]: Game crash in battles
- Dominant language
- C++
- Stars
- 8k
- Forks
- 351
- Avg merge
- 12h 31m
- Merged PRs (30d)
- 102
Description
**What Game**
Labyrinth of Touhou (Special Disc build). This is a Touhou fangame.
Official storefront: https://www.dlsite.com/home/work/=/product_id/RJ064430.html
I do have the English patches applied, but this crash also happens with an unpatched game.
**Describe the bug**
Entering a battle and attacking/using a spell results in the game hanging.
**To Reproduce**
Steps to reproduce the behavior:
1. Enter game and go through all the dialogue. (`Z` is effectively enter).
2. Go into the dungeon
3. Walk around until an encounter.
4. Do an attack or spell, game will hang.
**Expected behavior**
Battles do not crash using a traditional FEX 2508 rootfs. Have not been able test 2509.
I did try to build the arm64ec and wow64 FEX for wine using 2508 tag, but that did not fix the issue.
**Screenshots and Video**
The process to reproduce the error (I already have a minimal save file)
https://github.com/user-attachments/assets/d8634c7d-3e32-42d6-9e2c-16658dc7c232
**System information:**
- OS: Fedora 42
- CPU/SoC: Apple M2 under muvm (I did check this time)
- Video driver version: Mesa 25.2.0
- RootFS used: [eg: Ubuntu 21.10 Official Rootfs]
- FEX version: (FEXGetConfig --version) from source using 376d6ba72cacf869167695e64c899788e503008f
- Thunks Enabled: No
**Additional context**
- Is this an x86 or x86-64 game: x86
- Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested
- Is this a Vulkan game: Using wine's Direct3D9 emulation, trace seems to show a lot of OpenGL32.
The exception causing a problem is
```
0024:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=0000000000000000
0024:trace:seh:dispatch_exception info[0]=0000000000000008
0024:trace:seh:dispatch_exception info[1]=0000000000000000
0024:trace:seh:dispatch_exception pc=0000000000000000 sp=00007ffffe1ff2e0 lr=0000000000000000 fp=0000000000000008
0024:trace:seh:dispatch_exception x0=0000000000000000 x1=0000000000000000 x2=0000000000000000 x3=0000000000000000
0024:trace:seh:dispatch_exception x4=0000000000000000 x5=0000000000000001 x6=0000000000000000 x7=0000000000000000
0024:trace:seh:dispatch_exception x8=00000000001126ec x9=00000000034f0020 x10=000000000011290c x11=0000000000000000
0024:trace:seh:dispatch_exception x12=0000000000003ffe x13=0000000000000000 x14=0000000000003ffe x15=0000000000000000
0024:trace:seh:dispatch_exception x16=000000000000403e x17=0000004fffa2b680 x18=000000007ffc0000 x19=00007ffffe1ff310
0024:trace:seh:dispatch_exception x20=0000000000000000 x21=000000000000000c x22=0000000000000000 x23=000000000000007f
0024:trace:seh:dispatch_exception x24=00007ffffe1ff860 x25=00007ffffe39e7e0 x26=00000000001126e8 x27=00000000ffeed967
0024:trace:seh:dispatch_exception x28=00007fffff843090 cpsr=20000000 fpcr=00000000 fpsr=00000010
0024:warn:seh:virtual_unwind exception data not found for pc 0000000000000000, lr 0000000000000000
```
Which is weird since `pc` is 0.
I have attached a +trace,+seh log. Wine popped out 6.3GB of data, but since I know the event happened after pressing `Z` to do an attack, I grabbed the area between the last `GetKeyboardState` event and the spam of exceptions before a stack overflow.
[last_key.txt](https://github.com/user-attachments/files/22352133/last_key.txt)
The exception only happens on W-thread 24. I think this is the game thread with all of the wine3d3 and PeekMessageA I see.
W-thread 138 is where all the D3D to OpenGL emulation happens. W-thread 130 doesn't appear to do anything interesting.
This may be a red-herring, but the only instance of NtFlushInstructionCache I see is very close to the crash.
I am unable to use winedbg inside of muvm due to the tty emulation seemingly being broken. See https://github.com/AsahiLinux/muvm/issues/191
Interestingly I found a different error relating to an "invalid instruction" before I rebuilt FEX to a newer version. I haven't been able to find that error since.
Contributor guide
Assessment
This issue has not been assessed yet.