[Bug 54341] New: dotnet-dump data collection or some other backtrace for dotnet applications?

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
      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/

[Bug 54341] dotnet-dump data collection or some other backtrace for dotnet applications?

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54341

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 54341] dotnet-dump data collection or some other backtrace for dotnet applications?

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54341

Eric Pouech  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Eric Pouech  ---
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).

[Bug 54341] dotnet-dump data collection or some other backtrace for dotnet applications?

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54341

--- Comment #2 from Michael J Evans  ---
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

[Bug 54341] dotnet-dump data collection or some other backtrace for dotnet applications?

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54341

--- Comment #3 from Michael J Evans  ---
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.

[Bug 54341] dotnet-dump data collection or some other backtrace for dotnet applications?

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54341

--- Comment #4 from Eric Pouech  ---
(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.

[Bug 54341] dotnet-dump data collection or some other backtrace for dotnet applications?

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54341

Michael J Evans  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #5 from Michael J Evans  ---
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.

[Bug 54341] dotnet-dump data collection or some other backtrace for dotnet applications?

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54341

Gijs Vermeulen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Gijs Vermeulen  ---
Closing WORKSFORME.