http://bugs.winehq.org/show_bug.cgi?id=58742
Bug ID: 58742 Summary: winedbg: Internal crash at 00006FFFFF8CB5E5 (pe_load_msc_debug_info) Product: Wine Version: 10.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: winedbg Assignee: wine-bugs@winehq.org Reporter: zowie+wine@vandillen.io Distribution: ---
Platform: Linux Mint 21.3 Cinnamon Linux Kernel: 5.15.0-156-generic Platform 2: Linux Mint 22.2 Cinnamon Linux Kernel 2: 6.8.0-83-generic
When I build Wine myself and run the command `$WINE winedbg explorer` with it, it leads to a crash. This does not happen with the official builds of Wine, so I'm guessing there's some package version difference or something along those lines that makes this occur.
Log from a custom build of 10.15: ``` user@pc:~/wine/test$ $WINE winedbg explorer WineDbg starting on pid 0184 0180:fixme:dbghelp:elf_search_auxv can't find symbol in module 0180:fixme:dbghelp:elf_search_auxv can't find symbol in module winedbg: Internal crash at 00006FFFFF8CB5E5 user@pc:~/wine/test$ ```
Log from the official build of 10.15: ``` user@pc:~/wine/test$ wine winedbg explorer WineDbg starting on pid 01b4 01b0:fixme:dbghelp:elf_search_auxv can't find symbol in module 01b0:fixme:dbghelp:elf_search_auxv can't find symbol in module 0x006fffffc00c3d ntdll+0x10c3d: retq Wine-dbg> ```
The crash occurs in pe_load_msc_debug_info from pe_module.c, in the branch with `/* Debug info is stripped to .DBG file */`. The variable `dbg` is null, so it crashes when trying to dereference it.
Here's a quick fix I made for it. It fixes the crash but it doesn't really solve the underlying issue. As a result the debugger is missing so much debug information that it's not actually that helpful. ``` /* Read in debug directory */ dbg = RtlImageDirectoryEntryToData( mapping, FALSE, IMAGE_DIRECTORY_ENTRY_DEBUG, &nDbg ); nDbg = dbg ? nDbg / sizeof(IMAGE_DEBUG_DIRECTORY) : 0;
/* NEW */ if (!dbg) { pe_unmap_full(fmap); return ret; } /* END */
/* Parse debug directory */ ```
It's a bit annoying but for the time being I'll probably use the official build for debugging, or maybe I'll try to build Wine using the Docker set-up from the Gitlab CI.
http://bugs.winehq.org/show_bug.cgi?id=58742
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com
--- Comment #1 from Eric Pouech eric.pouech@gmail.com --- just trying to understand: - I assume you use a different explorer in the two cases (it likely picks the explorer provided by Wine, which probably use different compilation settings) - it could well be that loading your private build's explorer.exe in official build would also crash - your fix proposal looks good (I'll submit a slightly different version later on)
However, I can't repro the crash from a test inside the source tree, or after a regular installation (make install) or an installation with debug info stripped (make install INSTALL_PROGRAM_FLAGS=-s).
Can you share your configuration options and make & install commands
(also as a side note, not sure it matters, both your example use $WINE to refer to the wine executable. I assume it actually points to a different one...)
http://bugs.winehq.org/show_bug.cgi?id=58742
--- Comment #2 from Zowie zowie+wine@vandillen.io --- It's very strange but I made a fresh clone and went through the build process again for the sake of giving you a decent log to work with, and this time it just works. I'll try figuring out tomorrow what I was doing differently in my older builds. It could be WOW or it might be `CFLAGS="-Og" CROSSCFLAGS="-Og"`. Otherwise I wouldn't really know.
Either way, with the old private build it crashed for all executables. I used explorer as an example, but it also happens for executables I didn't compile myself, such as ones I got from the internet. I tried it with a game earlier with the same result: ``` WineDbg starting on pid 0128 0124:fixme:dbghelp:elf_search_auxv can't find symbol in module 0124:fixme:dbghelp:elf_search_auxv can't find symbol in module winedbg: Internal crash at 00006FFFFE93B5E5 ```
http://bugs.winehq.org/show_bug.cgi?id=58742
--- Comment #3 from Eric Pouech eric.pouech@gmail.com --- can you get debug info from your build now?
wow or CFLAGS shouldn't play a role here
the crash can only happen for an image file that has debug-stripped bit set and no debug directory present
'''winedump -f <img>''' should show DEBUG STRIPPED '''winedump -j debug <img>''' should show no information
but this could come from any loaded module in debugger (either main image, or any of the DLL)
if this happened for every app, it's likely that one of wine modules (potentially ntdll or kernelbase, for which winedbg always load debug info at startup) triggered the crash
cause outside of compilation/configuration options could come also from a truncated image file (out of disk space, or other causes...)
and a fresh compilation makes it vanish
http://bugs.winehq.org/show_bug.cgi?id=58742
--- Comment #4 from Zowie zowie+wine@vandillen.io --- I've tried to compile with and without optimization flags on my laptop just now and optimization flags are definitely the source of the problems. I've attached the logs of building Wine with and without the flags. Winedbg only crashes when building Wine with -Og.
Checking ntdll.dll on the one that crashes, ntdll.dll indeed has the DEBUG_STRIPPED characteristic, and `winedump -j debug ./ntdll.dll` dumps pretty much nothing. I've attached the printouts. The DLL only has 11 sections, as opposed to 19 sections when building without the optimization flags. The difference is the ".debug" sections, which aren't in the DLL with -Og.
http://bugs.winehq.org/show_bug.cgi?id=58742
--- Comment #5 from Zowie zowie+wine@vandillen.io --- Created attachment 79372 --> http://bugs.winehq.org/attachment.cgi?id=79372 Build & run winedbg with -Og
http://bugs.winehq.org/show_bug.cgi?id=58742
--- Comment #6 from Zowie zowie+wine@vandillen.io --- Created attachment 79373 --> http://bugs.winehq.org/attachment.cgi?id=79373 Build & run winedbg without -Og
http://bugs.winehq.org/show_bug.cgi?id=58742
--- Comment #7 from Zowie zowie+wine@vandillen.io --- Created attachment 79374 --> http://bugs.winehq.org/attachment.cgi?id=79374 ntdll.dll dump with -Og (broken)
http://bugs.winehq.org/show_bug.cgi?id=58742
--- Comment #8 from Zowie zowie+wine@vandillen.io --- Created attachment 79375 --> http://bugs.winehq.org/attachment.cgi?id=79375 ntdll.dll dump without -Og (working)
http://bugs.winehq.org/show_bug.cgi?id=58742
--- Comment #9 from Zowie zowie+wine@vandillen.io --- Created attachment 79376 --> http://bugs.winehq.org/attachment.cgi?id=79376 ntdll.dll dump -j debug with -Og (almost empty & pretty boring)
http://bugs.winehq.org/show_bug.cgi?id=58742
--- Comment #10 from Zowie zowie+wine@vandillen.io --- Created attachment 79377 --> http://bugs.winehq.org/attachment.cgi?id=79377 ntdll.dll dump -j debug without -Og (almost empty & pretty boring)
http://bugs.winehq.org/show_bug.cgi?id=58742
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
--- Comment #11 from Eric Pouech eric.pouech@gmail.com --- thanks for taking the time to look into the various configuration options
(note that using only -Og doesn't emit any debug information; you need -g or - gdwarf for that)
I'll submit a patch later on today
-
WineHQ Bugzilla