Document PROTON_DUMP_DEBUG_COMMANDS and issues with spaces in proton path

[ah-]

Hi,

I'm trying to spend some time trying to fix various games for fun, but I'm finding it hard to get a debugger attached early enough to catch launch issues.

Usually the program exits before I can attach to it, so I'm just relying on crashdumps (which are often a bit incomplete and don't have a full/correct stack trace), wine +relay logs and luck.

I just discovered PROTON_DUMP_DEBUG_COMMANDS which looks pretty promising!
However, I don't fully understand yet how winedbg_run and gdb_run are meant to be used.
Just running one of them and starting the program with c seems to not attach gdb/winedbg to the running program, they start, crash, and gdb just tells me that the program exited but doesn't break.
Trying to b main or similar doesn't seem to set breakpoints correctly either.

Do you have any hints how to best go about debugging? What do you usually do?

Sorry if I've missed something obvious, I just figured it'd be easier to just ask.

I've also noticed that winedbg_run sometimes has issues with the space in "Proton 3.7", e.g.:

/tmp/winegdb.iy8qJR:1: Error in sourced command file:
/home/andreas/.local/share/Steam/steamapps/common/Proton: No such file or directory.

Creating a symlink without the space fixes that issue.

[4LT]

Have you tried messing with the launch options? I've used that to debug source mods before by launching a terminal and having it execute a script. I'm not at my desktop right now, so I don't know the exact command, but it was something like your-favorite-terminal --someswitch bash -c "gdb /path/to/executable" && echo %command%

[ah-]

Thanks, yes I have a bit, but so far with limited success. I think what you're suggesting makes sense, but it seems that the scripts that PROTON_DUMP_DEBUG_COMMANDS creates make that part unnecessary. They seem to already give me a way of directly launching executables instead of just telling steam to launch them for me.

However, I can't figure out how to directly get e.g. winedbg attached properly and break when anything goes wrong.

[aeikum]

Thanks for reporting. The spaces issue will be fixed in the next build. In the meantime, you can workaround by putting quotes around the path in the first line of that /tmp/ file.

The scripts are sparely documented at the top of each script. They could be more thorough, I guess, but they're each like 3 lines long and shouldn't be too hard to figure out alongside the winedbg manpage. They're not really intended for use by end-users.

Note that winedbg itself isn't terribly robust or well documented, but that's not a Proton issue per se =/

Here's a super trivial session example (with some junk trimmed):

[aeikum@aeikum ~]$ /tmp/proton_aeikum/gdb_run 
0027:0028: create process ''/0x110c90 @0x4f9a16 (0<0>)
0027:0028: create thread I @0x4f9a16
...
0027:0028: loads DLL  @0x7d300000 (0<0>)
00000027:00000028: exception code=0x80000003
warning: remote target does not support file transfer, attempting to access files from local filesystem.
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
start_process (entry=0x4f9a16, peb=0x7ffdf000) at /home/proton/proton/wine/dlls/kernel32/process.c:1099
1099	/home/proton/proton/wine/dlls/kernel32/process.c: No such file or directory.


Wine-gdb> break SetWindowPos
Breakpoint 1 at 0x7e756770: file /home/proton/proton/wine/dlls/user32/winpos.c, line 2338.


Wine-gdb> c
Continuing.
...
00000027:00000028: exception code=0x80000003

Breakpoint 1, SetWindowPos (hwnd=0x2004e, hwndInsertAfter=0x0, x=0, y=0, cx=0, cy=0, flags=67) at /home/proton/proton/wine/dlls/user32/winpos.c:2338
2338	/home/proton/proton/wine/dlls/user32/winpos.c: No such file or directory.


Wine-gdb> bt
#0  SetWindowPos (hwnd=0x2004e, hwndInsertAfter=0x0, x=0, y=0, cx=0, cy=0, flags=67) at /home/proton/proton/wine/dlls/user32/winpos.c:2338
#1  0x7e757aa2 in show_window (hwnd=0x2004e, cmd=5) at /home/proton/proton/wine/dlls/user32/winpos.c:1152
#2  0x7e757d48 in ShowWindow (hwnd=0x2004e, cmd=5) at /home/proton/proton/wine/dlls/user32/winpos.c:1250
#3  0x0067dc15 in ?? ()
#4  0x0067c1b5 in ?? ()
#5  0x004f2158 in ?? ()
#6  0x004c49e3 in ?? ()
#7  0x004c4836 in ?? ()
#8  0x00437164 in ?? ()
#9  0x004f9b41 in ?? ()
#10 0x7b4611dc in call_process_entry () from /home/aeikum/.local/share/Steam/steamapps/common/Proton 3.7 Beta/dist/bin/../lib/wine/kernel32.dll.so
#11 0x7b462a36 in start_process (entry=0x4f9a16, peb=0x7ffdf000) at /home/proton/proton/wine/dlls/kernel32/process.c:1099
#12 0x7b4611ea in start_process_wrapper () from /home/aeikum/.local/share/Steam/steamapps/common/Proton 3.7 Beta/dist/bin/../lib/wine/kernel32.dll.so
#13 0x00000000 in ?? ()


Wine-gdb>

Edit: I tried to make the input prompts more obvious.

[ah-]

Great, that's really helpful!

I know it's a pretty broad question, but do you have any other wine debugging tips, in particular around games? Or general resources? I've read through the wine debugging FAQ, but can't shake the feeling that there are more tricks most wine devs just know.

E.g. breaking on SetWindowPos seems to be a pretty good idea in my use case, as it breaks pretty soon before where I suspect it crashes.

[aeikum]

For me, debugging Wine issues, I use the debug log most often. I rarely use a debugger. Add log channels relevant to the problem you're having, and look for err: and warn: lines for obvious failures. If the program is just quitting unexpectedly, you can add +relay and look backwards from ExitProcess to find the last bit of what looks like "normal processing" to find the failure. +seh will show you exceptions, c0000005 indicates a bad pointer dereference, which will often be preceded by some sort of failure.

[ah-]

Cool thanks! Managed to make Little Nightmares run somewhat yesterday evening, partly thanks to your hints :)

Closing for now, but I'd love to have a bit more of a guide or collections of hints like that at some point. I'd write up some myself, but I don't think I know quite enough yet.