https://bugs.winehq.org/show_bug.cgi?id=55039
Bug ID: 55039 Summary: Touhou 12.3 : specific attack randomly causes online desync Product: Wine Version: 8.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: riyu12383@gmail.com Distribution: ---
Created attachment 74605 --> https://bugs.winehq.org/attachment.cgi?id=74605 Game replay file, showing the chain attack causing desync
--The game I already presented this game with it's download link in this issue : https://bugs.winehq.org/show_bug.cgi?id=54916
--The bug This game is a fighting game, which is supposed to be deterministic. In online game, there's no main server, the 2 opponents only receive the input of the other player directly from each others.
A specific attack (Remilia's chain gang) randomly behave abnormally on Linux, the attack's collision boxes aren't generated, thus altering the flow of the game, de-syncing the game in online.
The attack consist of a metal chain, which appears chain link by chain link, following the other player trying to grab him. This attack seems slightly more complex to implement than the others.
When bugged, the attack seems to be mixed with another variant of it, where the chain is shorter and the collision boxes are supposed to appear when the chain disappears.
Usually in other games similar issues, online desync is resolved by installing Microsoft visual redistributable, but here it doesn't solve the issue.
This bug is random, even with the same wine version it still occurs randomly on the same replay file.
--Replay file Here attached is a replay file, to be put in the "replay" folder inside the game folder. Going to the "replay" menu in the main game menu, you can replay a game.
To directly see the collision boxes, please remove the ";" before the line "ReplayInputView+=" in the SWRSToys.ini file, and launch the game with WINEDLLOVERRIDES="d3d9=n,b" to load mods. When replaying the game, press F4 to see the collision boxes.
Beside the initial chain summoning, the chain should always instantly get collision boxes.
If the bug occurs, the player attack will miss the other player, and will after likely be too far to reach the other player ever again with the chain.
--Tried regression test This issue is not a regression, the bug has been known in the game community for ages. But I observed on my machine a more frequent occurrence in modern wine builds. This might likely be an illusion of mine based on coincidence, as the bug is extremely random and I don't have a clear way to separate good and bad in the bisection, as the bug will always occurs with given time on any builds. My first try led me to 27665f35e4da13bac1e4dd8948a65f484c9dadfa, but with further testing it actually didn't really had an impact, but 2 commits later at 40b7c3e89a95d6ccb190b234d4ad13b3a8304495 it seems way more frequent, but I'm not even sure if it's this one or the commit before. I still believe it is unrelated to the actual issue origin, and even might just be an illusion/coincidence of my own.
https://bugs.winehq.org/show_bug.cgi?id=55039
YuriK7 riyu12383@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=55039
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #1 from Zeb Figura z.figura12@gmail.com --- (In reply to YuriK7 from comment #0)
Usually in other games similar issues, online desync is resolved by installing Microsoft visual redistributable, but here it doesn't solve the issue.
It's been observed in the past (although never on a public bug tracker as far as I'm aware) that Wine's CRT math functions sometimes differ from Windows' simply by virtue of rounding to the nearest LSB, and some applications use these to compute a hash and then fail when the hashes don't match. That *may* be what's going on here, although the description of the application glitching out is a bit odd—the error should in theory be small enough that it wouldn't cause an observable physics desync?
In this case it may still be possible to override the CRT. Which CRT did you try to install? Can you attach a log from this game with WINEDEBUG=+loaddll?
https://bugs.winehq.org/show_bug.cgi?id=55039
--- Comment #2 from YuriK7 riyu12383@gmail.com --- Created attachment 74610 --> https://bugs.winehq.org/attachment.cgi?id=74610 Log file of the game with loaded dll
https://bugs.winehq.org/show_bug.cgi?id=55039
--- Comment #3 from YuriK7 riyu12383@gmail.com --- (In reply to Zeb Figura from comment #1)
In this case it may still be possible to override the CRT. Which CRT did you try to install? Can you attach a log from this game with WINEDEBUG=+loaddll?
By CRT you mean C runtime ? We're pretty sure that the game uses msvcr100 as there's a known issue of missing dll on windows. I even tried vcrun6 to 2015.
I've attached log of the game without mods.
https://bugs.winehq.org/show_bug.cgi?id=55039
--- Comment #4 from Zeb Figura z.figura12@gmail.com --- (In reply to YuriK7 from comment #3)
(In reply to Zeb Figura from comment #1)
In this case it may still be possible to override the CRT. Which CRT did you try to install? Can you attach a log from this game with WINEDEBUG=+loaddll?
By CRT you mean C runtime ? We're pretty sure that the game uses msvcr100 as there's a known issue of missing dll on windows. I even tried vcrun6 to 2015.
Yes. The log doesn't show it loading msvcr100, only msvcrt and ucrtbase. If you tried vcrun2015, though, that'd provide ucrtbase, so perhaps that's not the problem after all.
https://bugs.winehq.org/show_bug.cgi?id=55039
--- Comment #5 from YuriK7 riyu12383@gmail.com --- Created attachment 74611 --> https://bugs.winehq.org/attachment.cgi?id=74611 Expected behavior
The chain has it's collision boxes, it can grab the other player.
https://bugs.winehq.org/show_bug.cgi?id=55039
--- Comment #6 from YuriK7 riyu12383@gmail.com --- Created attachment 74612 --> https://bugs.winehq.org/attachment.cgi?id=74612 Actual behavior
The chain doesn't have any collision boxes, it goes through the other player without dealing any damage and grabbing them.
https://bugs.winehq.org/show_bug.cgi?id=55039
YuriK7 riyu12383@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|8.9 |8.10
--- Comment #7 from YuriK7 riyu12383@gmail.com --- The bug still occurs with wine 8.10.
If it could be of any help, here are links to known game addresses and mods repo : https://github.com/SokuDev/SokuLib/blob/master/src/SokuAddresses.hpp https://github.com/SokuDev/SokuMods
https://bugs.winehq.org/show_bug.cgi?id=55039
YuriK7 riyu12383@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://soku.delthas.fr/
https://bugs.winehq.org/show_bug.cgi?id=55039
YuriK7 riyu12383@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|8.10 |8.14
--- Comment #8 from YuriK7 riyu12383@gmail.com --- I have found a workaround that fix this bug and did confirmed it with other players. Launching the game with WINEDEBUG=warn+heap fixes the issue, while WINEDEBUG=warn+all,-heap doesn't. Enabling the heap debug channel fixes the issue even though there is no additional printed logs.
https://bugs.winehq.org/show_bug.cgi?id=55039
Etaash Mathamsetty etaash.mathamsetty@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |etaash.mathamsetty@gmail.co | |m
--- Comment #9 from Etaash Mathamsetty etaash.mathamsetty@gmail.com --- (In reply to Zeb Figura from comment #4)
(In reply to YuriK7 from comment #3)
(In reply to Zeb Figura from comment #1)
In this case it may still be possible to override the CRT. Which CRT did you try to install? Can you attach a log from this game with WINEDEBUG=+loaddll?
By CRT you mean C runtime ? We're pretty sure that the game uses msvcr100 as there's a known issue of missing dll on windows. I even tried vcrun6 to 2015.
Yes. The log doesn't show it loading msvcr100, only msvcrt and ucrtbase. If you tried vcrun2015, though, that'd provide ucrtbase, so perhaps that's not the problem after all.
isn't ucrtbase always builtin, or it is at least on proton based wine
https://bugs.winehq.org/show_bug.cgi?id=55039
--- Comment #10 from Etaash Mathamsetty etaash.mathamsetty@gmail.com --- nevermind seems to be native,builtin on my wine staging install
https://bugs.winehq.org/show_bug.cgi?id=55039
--- Comment #11 from YuriK7 riyu12383@gmail.com --- Using Application Verifier from MS to debug th123.exe directly in Windows, we found that everytime we do that specific attack, it will throw an access violation exception (0xC0000005) on the instruction (fcomp dword ptr [ecx+10h]) at 0x005a4029.
https://bugs.winehq.org/show_bug.cgi?id=55039
--- Comment #12 from YuriK7 riyu12383@gmail.com --- The issue has been fixed with a mod. While the original game still suffers the issue, most players use the community edition that will be fix in the next release. The previously mentioned instruction with access violation is part of the chain link update function. The problem is that the initial attack's object is instantiated at 0x00590683 with its last parameter 4 being a wrong value as it should been 5. It is later on use on an operator_new allocation function (0x0059be86) and a memcpy (0x0059bea6), resulting on a unallocated memory accessed by the chain link update function later on.
This is a bug from the game itself, but if I understand correctly, Windows uses padding with its heap allocation, and this behavior is only enabled on wine with warn+heap and that is why using it prevented the issue similarly as on Windows. Is something preventing to enable this outside of warn+heap ?
https://bugs.winehq.org/show_bug.cgi?id=55039
--- Comment #13 from YuriK7 riyu12383@gmail.com --- On a side-note, the bug is triggered if and only if the unallocated memory accessed equals to float zero as far as we know.
https://bugs.winehq.org/show_bug.cgi?id=55039
hagb@hagb.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hagb@hagb.name
--- Comment #14 from hagb@hagb.name --- Created attachment 75113 --> https://bugs.winehq.org/attachment.cgi?id=75113 A minimal working example
$ i686-w64-mingw32-gcc mwe.c -o mwe.exe $ wine mwe.exe 1.073114e-41, 0x00001dea 9.248570e-44, 0x00000042 8.828180e-44, 0x0000003f 8.407791e-44, 0x0000003c 7.987401e-44, 0x00000039 0.000000e+00, 0x00000000 0.000000e+00, 0x00000000 0.000000e+00, 0x00000000 $ WINEDEBUG=warn+heap wine mwe.exe -1.219793e-12, 0xabababab -1.219793e-12, 0xabababab -1.219793e-12, 0xabababab -1.219793e-12, 0xabababab -1.219793e-12, 0xabababab -1.219793e-12, 0xabababab -1.219793e-12, 0xabababab -1.219793e-12, 0xabababab
https://bugs.winehq.org/show_bug.cgi?id=55039
YuriK7 riyu12383@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|8.14 |8.15 Component|-unknown |ntdll
https://bugs.winehq.org/show_bug.cgi?id=55039
--- Comment #15 from YuriK7 riyu12383@gmail.com --- Created attachment 75974 --> https://bugs.winehq.org/attachment.cgi?id=75974 Force padding
Changing this condition enables heap padding and "fixes" this issue. Is there any reason why it is not enabled by default ?
https://bugs.winehq.org/show_bug.cgi?id=55039
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #16 from Fabian Maurer dark.shadow4@web.de ---
Changing this condition enables heap padding and "fixes" this issue. Is there any reason why it is not enabled by default ?
Because the tests show that windows doesn't behave like that. Not sure what exactly is different on windows that makes it work though.
-
WineHQ Bugzilla