search

ValveSoftware / Proton

Compatibility tool for Steam Play based on Wine and additional components
Other
24.17k stars 1.06k forks source link

SHENZHEN I/O (504210) #5715

Open magicvodi opened 2 years ago

magicvodi commented 2 years ago

Hello,

the Steam Deck Verified title SHENZHEN I/O crashes on my Steam Deck when I try to input text in the game.

My Steam Deck is on Beta Channel, I already tried different Proton versions.

It doesn't matter if I try to enter the text via controller macros or the virtual keyboard.

Attached are the files generated by the SHENZHEN I/O crash reporter. shenzhen-save-directory.zip shenzhen-crash-report.html.txt

If you need additional information I'm happy to help

.

Blisto91 commented 2 years ago

Does it work via the native version? Obviously it shouldn't crash whether it's running via proton or native, but just out of interest.

magicvodi commented 2 years ago

Oh, I didn't even realize it has a native version. It crashes on native. Where can I report a bug with steam verified title?

Blisto91 commented 2 years ago

Hmm I'm not sure. If it's the native version then I'd be inclined to say the bug needs to be reported to the game devs. Tho if the issue is isolated to the steam deck then i dunno if you should post in the steam discussion forums or on the steam for linux github.

@kisak-valve Might be able to provide some guidance.

magicvodi commented 2 years ago

It seems like its the "native" version, I thought it must be proton because there were some Windows informations and dlls in the crash report. I already sent it to the dev and I will try to test it on another computer with linux.

Blisto91 commented 2 years ago

I agree it does look a bit weird if it's running the native version when it posts this in the crash logs 🤔 

SYSTEM INFO:

Platform: Win32NT (2)
OS version: Microsoft Windows NT 10.0.19043.0
OS version (uname): N/A
OS is 64-bit: True
Detected OS: Windows
.NET runtime version: 4.0.30319.42000
Running on Mono: True
Process is 64-bit: False

DirectX adapter #0
AMD RADV VANGOGH

DLL diagnostic:
  d3d11.dll: yes
  dxgi.dll: yes
  dwrite.dll: yes
  msvcr110.dll: yes
  vcruntime140.dll: yes

It looks like the steam deck is running it through proton.

kisak-valve commented 2 years ago

Hello @magicvodi, please add PROTON_LOG=1 %command% to the game's launch options and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.)

magicvodi commented 2 years ago

I got a log file, so we can assume its running through proton? steam-504210.log

magicvodi commented 2 years ago

FYI when I install it in Linux on my PC it runs the native version, which works without problems. When I run it through Proton 7, it crashes like on the Steam Deck

Blisto91 commented 2 years ago

Ye it's running Proton then. Unless the game has issues i would think the steam deck should default to native.

Tho it obviously shouldn't crash anyway so it would be nice to fix the issue if it influences other games.

magicvodi commented 2 years ago

Unless the game has issues i would think the steam deck should default to native.

It just reinstalled it on the Steam Deck and it definitely downloads the Windows Version (theres a Shenzhen.exe and no Shenzhen.bin.x86_64 like on my PC)

I also opened a bug report in the Steam Deck Forum

magicvodi commented 2 years ago

I just found out one can force to run the native version on the steam deck which works without crashing.

flibitijibibo commented 2 years ago

Developer of the Linux version here... this behavior on Deck was not what we asked for, but at the same time I don't have partner access for this title so I can't resubmit. If at all possible it'd be great to have this requeued on Valve's end.

flibitijibibo commented 2 years ago

The default depot should now be fixed.

normanr commented 1 year ago

Openbsd worked around it by suppressing the exception: https://github.com/rfht/fnaify/issues/34

normanr commented 1 year ago

btw, it looks List<Chip> in Solution is changed while the UI thread is busy looping through the same list to render the Chips to the screen. Disabling the Sort() (it unconditionally increases the version) with ShenzhenMod prevents the crash (but I'm not sure how important it is that the list is sorted correctly). I also didn't look to see which call-site is the cause. I suspect the ones that serialize the Solution state to StringBuilder are the culprit because they seem to be called when the chip is changed.

Update: I changed my patch to do the Sort() conditionally (only if the list is not already sorted) and it works great.

madewokherd commented 1 year ago

This is very interesting. Someone should probably test native .NET Framework to see if it has the same behavior when Sort() is called on an already-sorted list. Perhaps Mono's Sort() method is wrong.

madewokherd commented 11 months ago

Testing on Windows shows that List<T>.Sort() always increases the version, but List<T>.Sort(Comparison<T>) never increases the version. So it looks like a .NET Framework bug that SHENZHEN I/O inadvertently takes advantage of.

madewokherd commented 11 months ago

Pushed a change to match Framework's bug: https://github.com/madewokherd/wine-mono/commit/d7f93e4d9a29f9675172551f7fcd4d188b5f659d

normanr commented 11 months ago

Testing on Windows shows that List<T>.Sort() always increases the version, but List<T>.Sort(Comparison<T>) never increases the version. So it looks like a .NET Framework bug that SHENZHEN I/O inadvertently takes advantage of.

That's strange, because the code in dotnet's System.Collections.Generic.List increments the version in both code paths.

madewokherd commented 11 months ago

That'd be the current version of .NET (descended from .NET Core), not .NET Framework. My guess is they fixed the bug there but had to leave it in Framework for compatibility. And Mono shares that code, which is why it behaves correctly (as opposed to the broken way this application requires) in Mono.