[Bug 54341] New: dotnet-dump data collection or some other backtrace for dotnet applications?
https://bugs.winehq.org/show_bug.cgi?id=54341 Bug ID: 54341 Summary: dotnet-dump data collection or some other backtrace for dotnet applications? Product: Wine Version: 7.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mjevans1983(a)gmail.com Distribution: --- Created attachment 73910 --> https://bugs.winehq.org/attachment.cgi?id=73910 winedbg.exe dump during the livelock I'm trying to figure out why a game (Cosmoteer again) freezes when multi-threading is enabled. The current work around is to run it in 'single core' ( --cores 1 ) mode, but obviously the performance is quite inferior for an application intended to run on multiple cores. On my system when it's briefly working it uses between 300 and 500% of a core (so 3-5 physical cores on a 4c8t system). I need to collect more data to isolate if it's an issue with the game or with wine, and I don't even know where to begin looking for Wine data since I can't get a backtrace from any tools. gdb doesn't know about applications that run through wine. winedbg doesn't appear to understand dotnet managed applications (attachment) I tried to run dotnet-dump but the tool installed in Linux doesn't locate any applications that it can interact with, while the 64-bit (matches the program) version of the tool inside wine appears to want a full dotnet install. https://github.com/dotnet/diagnostics/blob/main/documentation/single-file-to... So much for a single file tool ~.~ Is there some way I could collect more data without help from the program's creator? I've already suggested they please trap SIGTERM, SIGINT, SIGQUIT, and SIGHUP but I don't even know if that will work for an application using wine. https://steamcommunity.com/app/799600/discussions/1/3762228045904230736/ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54341 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54341 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech(a)gmail.com --- Comment #1 from Eric Pouech <eric.pouech(a)gmail.com> --- one of the issue is to understand why the game freezes... I'm not convinced that running a managed code capable debugger will help you. It may give the backtrace of the blocked threads (if it's a deadlock), but it won't tell you why this happended. One way forward: - run the game with WINEDEBUG=+relay and then try to get why the game is stuck from that log. that's tedious. tools/examine-relay can help triaging that log. If you really want to debug it, one item that may work is to use a MS debugger (eg WinDbg) from a full fledged windows setup and to use the remote debugging from windbg (running the remote stub + your game under wine). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54341 --- Comment #2 from Michael J Evans <mjevans1983(a)gmail.com> --- After reading it again I noticed something on https://github.com/dotnet/diagnostics/blob/main/documentation/single-file-to... which wasn't on the main documentation I'd mostly been looking at. DOTNET_ROOT I tried setting this to the game's binary path where it looked like it might have a copy of the runtime. Didn't work. With that still set I downloaded the windows x64 '.net runtime' which required human interaction to install. https://dotnet.microsoft.com/en-us/download/dotnet/6.0 After that dotnet-dump (64 bit windows) worked, though I still had to have set DOTNET_ROOT=pathabove . I also tried https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-stack but rather than dump the threads as I hoped it just froze for ~10 min. clrstack -all is what I was looking for, but the sub-argument is not directly documented on the pages linked above! cd \path\to\dotnet-dump64.exe set DOTNET_ROOT="Z:\home\USER\.local\share\Steam\steamapps\common\Cosmoteer\Bin" dd64 analyze dump_20230119_131617.dmp -c "clrstack -all" > somefile.txt -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54341 --- Comment #3 from Michael J Evans <mjevans1983(a)gmail.com> --- Created attachment 73916 --> https://bugs.winehq.org/attachment.cgi?id=73916 dotnet-dump of Cosmoteer during livelock, unsure if WineBug yet... I'm unsure if this is a wine bug or an application bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54341 --- Comment #4 from Eric Pouech <eric.pouech(a)gmail.com> --- (In reply to Michael J Evans from comment #3)
Created attachment 73916 [details] dotnet-dump of Cosmoteer during livelock, unsure if WineBug yet...
I'm unsure if this is a wine bug or an application bug.
hard to be 100% sure, but from the log it looks like most of the threads are in wait state. But can't tell what they are waiting for. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54341 Michael J Evans <mjevans1983(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Michael J Evans <mjevans1983(a)gmail.com> --- Yeah, the game's author also replied and thinks it might be related to a known bug. If they get any info pointing back towards wine I'll likely invest additional effort on areas I am able to introspect and report on issues from. However the few wine related functions seem likely to be _super_ well treaded and the issue only happens while the game's doing it's own attempt at 'high performance threading'? That's a known very difficult problem domain and the most likely culprit; at least to the point of needing to be ruled out first. I also located a workaround for getting dotnet-dump to work, by installing the core runtime and setting an environment variable. So for now this looks closed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54341 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Closing WORKSFORME. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla