[Bug 60004] New: dbghelp crashes while trying to display SuperTux crash stacktrace
http://bugs.winehq.org/show_bug.cgi?id=60004 Bug ID: 60004 Summary: dbghelp crashes while trying to display SuperTux crash stacktrace Product: Wine Version: 11.13 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: dbghelp Assignee: wine-bugs@list.winehq.org Reporter: tobbi.bugs@googlemail.com Target Milestone: --- Created attachment 81410 --> http://bugs.winehq.org/attachment.cgi?id=81410 console output % ./wine --version wine-11.13 % openssl sha256 SuperTux\ profile\ data.zip SHA2-256(SuperTux profile data.zip)= 74e272380c9211a22c2fd9858095ac7209ce44e4ecbbd382817147841896eac9 % openssl sha256 windows-x64-RelWithDebInfo-v0-7-0-steam-a0c7dab-portable.zip SHA2-256(windows-x64-RelWithDebInfo-v0-7-0-steam-a0c7dab-portable.zip)= c5ed4261954c3cbb58c649d767c27c1332d47cc26e2bfc060add15861b95eed I noticed that dbghelp itself crashes when trying to report an error that occurs when playing a SuperTux build with a particular set of SuperTux profile data. Steps to reproduce: 1. Create a new wine prefix. 2. Download the SuperTux profile data.zip file from http://tobbi.bplaced.net/krams/SuperTux%20profile%20data.zip and extract it into your newly created wine prefix under drive_c/users/<your username>/AppData/Roaming/ so that the directory structure looks like this: drive_c/users/<your username>/AppData/Roaming/SuperTux/supertux2/ drive_c/users/<your username>/AppData/Roaming/SuperTux/supertux2/addons drive_c/users/<your username>/AppData/Roaming/SuperTux/supertux2/config drive_c/users/<your username>/AppData/Roaming/SuperTux/supertux2/profile1 ... 3. Download the SuperTux build from here and extract it: tobbi.bplaced.net/krams/windows-x64-RelWithDebInfo-v0-7-0-steam-a0c7dab-portable.zip 4. Start the build like this: % WINEPREFIX=~/SOME_NEW_SUPERTUX ./wine ./windows-x64-RelWithDebInfo-v0-7-0-steam-a0c7dab-portable/bin/supertux2.exe &> wine _stacktrace_viewer_errors.txt 5. Click "Start Game". 6. In the upcoming wine error dialog, click the button "Show details". Expected results: The details are shown Actual results: Wine error dialog crashes -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #1 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Created attachment 81411 --> http://bugs.winehq.org/attachment.cgi?id=81411 SuperTux profile data -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 Eric Pouech <eric.pouech@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com --- Comment #2 from Eric Pouech <eric.pouech@gmail.com> --- where did you get your Wine binaries? (compiled yourself, from which distro?) (as it's very likely crash occurs when loading dwarf info from one of the Wine modules) in the trace, the last 'Unhandled attr op' don't look good. it sounds like either dwarf parser is desynchronized wrt. dwarf input, or memory has been thrashed. can you post the WINEDEBUG=+dbghelp output so that we can narrow down the offending module? TIA -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #3 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Created attachment 81415 --> http://bugs.winehq.org/attachment.cgi?id=81415 WINEDEBUG=+dbghlp output -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #4 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- (In reply to Eric Pouech from comment #2)
where did you get your Wine binaries? (compiled yourself, from which distro?) (as it's very likely crash occurs when loading dwarf info from one of the Wine modules)
I compiled wine myself on MacOS 12.7.6 using gcc. If you need any more info regarding my build environment, I can surely provide that.
in the trace, the last 'Unhandled attr op' don't look good. it sounds like either dwarf parser is desynchronized wrt. dwarf input, or memory has been thrashed.
can you post the WINEDEBUG=+dbghelp output so that we can narrow down the offending module?
Uploaded.
TIA
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81415|0 |1 is obsolete| | --- Comment #5 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Created attachment 81416 --> http://bugs.winehq.org/attachment.cgi?id=81416 WINEDEBUG=+dbghelp output I noticed that the debugging channel is called `dbghelp`. Here's the log output for that. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #6 from Eric Pouech <eric.pouech@gmail.com> --- Created attachment 81417 --> http://bugs.winehq.org/attachment.cgi?id=81417 patch to debug thanks for the reply. from that: - crash happens when loading Wine's dinput8.dll debug info. Just for sake of mind, can you recompile that module and see what gives? (just to be sure there's no thrashed content in that file) - can you share the way you configured Wine for compilation (./configure options mainly) and potentially toolchain (and version) used in compilation? - since we have some garbled reading of line number info (from winedbg in dwarf2_parse_line_number_numbers), and that function doesn't check if line_range variable is not 0 before going into a division, a wild guess would be that it reads a 0 value in line_range. It still doesn't explain why it gets here. Can you apply the attached patch and recompile and post the output of WINEDEBUG=+dbghelp,warn+dbghelp_dwarf the patch should mainly serve for dumping the dwarf line number header information, perhaps to see where it could go south patch also includes a potential fix when dwarf format uses 64bit offsets (instead of default32 bit), but I also doubt it shall be the culprit TIA -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #7 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- (In reply to Eric Pouech from comment #6)
Created attachment 81417 [details] patch to debug
thanks for the reply. from that: - crash happens when loading Wine's dinput8.dll debug info. Just for sake of mind, can you recompile that module and see what gives? (just to be sure there's no thrashed content in that file)
I deleted both output directories for that module and recompiled. Crash still occurs.
- can you share the way you configured Wine for compilation (./configure options mainly) and potentially toolchain (and version) used in compilation?
I configured wine using these configure flags (mostly taken from https://github.com/Gcenx/macOS_Wine_builds#configure-options ) build=x86_64-apple-darwin --enable-archs=i386,x86_64 --disable-tests --disable-winebth_sys --without-alsa --without-capi --with-coreaudio --with-cups --without-dbus --with-ffmpeg --with-freetype --with-gettext --without-gettextpo --without-gphoto --with-gnutls --without-gssapi --with-gstreamer --with-inotify --without-krb5 --with-mingw=/opt/local/libexec/llvm-mingw/bin/clang --without-netapi --with-opencl --without-opengl --without-oss --with-pcap --without-pcsclite --with-pthread --without-pulse --without-sane --with-sdl --without-udev --without-usb --without-v4l2 --without-vulkan --without-wayland --without-x build_alias=x86_64-apple-darwin % /opt/local/libexec/llvm-mingw/bin/clang --version clang version 22.1.7 (https://github.com/llvm/llvm-project.git a255c1ed36a1d06f79bd2633ba9f8d900153007c) Target: arm64-apple-darwin21.6.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-mingw/bin
- since we have some garbled reading of line number info (from winedbg in dwarf2_parse_line_number_numbers), and that function doesn't check if line_range variable is not 0 before going into a division, a wild guess would be that it reads a 0 value in line_range. It still doesn't explain why it gets here. Can you apply the attached patch and recompile and post the output of WINEDEBUG=+dbghelp,warn+dbghelp_dwarf
I will upload the file shortly.
the patch should mainly serve for dumping the dwarf line number header information, perhaps to see where it could go south patch also includes a potential fix when dwarf format uses 64bit offsets (instead of default32 bit), but I also doubt it shall be the culprit
TIA
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #8 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Created attachment 81420 --> http://bugs.winehq.org/attachment.cgi?id=81420 WINEDEBUG=+dbghelp,warn+dbghelp_dwarf output -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #9 from Eric Pouech <eric.pouech@gmail.com> --- (In reply to Tobias (:Tobbi) Markus from comment #8)
Created attachment 81420 [details] WINEDEBUG=+dbghelp,warn+dbghelp_dwarf output
thanks for the quick response... unfortunately, none of the leads end up with something usable from the traces, it looks like you run Wine from the build tree could you attach the file Z:\\Volumes\\Development\\workspace\\wine\\dlls\\dinput8\\x86_64-windows\\dinput8.dll? (side note, winedbg has issues later on, but likely on another file, but let start with the first crash) TIA -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #10 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Created attachment 81422 --> http://bugs.winehq.org/attachment.cgi?id=81422 dinput8.dll -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 Eric Pouech <eric.pouech@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81417|0 |1 is obsolete| | --- Comment #11 from Eric Pouech <eric.pouech@gmail.com> --- Created attachment 81424 --> http://bugs.winehq.org/attachment.cgi?id=81424 patch1 the attached patch fixes locally the crash when loading dinput8.dll (thanks for posting the .dll, it's much easier ;-)) would you mind testing if it works for you? (reverting the first patch, it's no longer needed) if it does, regarding the other(?) potential issue about the "strange" op attr, would mind running: WINEDEBUG=+dbghelp,warn+dbghelp_dwarf ./wine winedbg SupertTux2.exe (hitting 'cont<cr>' to force debugger to launch program) and post the resulting trace TIA -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #12 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- (In reply to Eric Pouech from comment #11)
Created attachment 81424 [details] patch1
the attached patch fixes locally the crash when loading dinput8.dll (thanks for posting the .dll, it's much easier ;-)) would you mind testing if it works for you? (reverting the first patch, it's no longer needed)
I applied the patch and ran SuperTux. Now, without running with a debugger, I'm getting a SuperTux crash dialog (We implemented our own crash dialog that supports reporting crashes and posting stack traces in github issues). I'm gonna report the info there in a second.
if it does, regarding the other(?) potential issue about the "strange" op attr, would mind running: WINEDEBUG=+dbghelp,warn+dbghelp_dwarf ./wine winedbg SupertTux2.exe (hitting 'cont<cr>' to force debugger to launch program) and post the resulting trace TIA
I'll upload the file in a second. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #13 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Created attachment 81425 --> http://bugs.winehq.org/attachment.cgi?id=81425 WINEDEBUG=+dbghelp,warn+dbghelp_dwarf ./wine winedbg supertux2.exe output -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #14 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- The internal SuperTux debugger reports a crash in __CxxUnregisterExceptionObject . No other stack trace, just that one frame. I don't know if this is even relevant at this point. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #15 from Eric Pouech <eric.pouech@gmail.com> --- (In reply to Tobias (:Tobbi) Markus from comment #14)
The internal SuperTux debugger reports a crash in __CxxUnregisterExceptionObject . No other stack trace, just that one frame. I don't know if this is even relevant at this point.
winedbg prints as back trace: Unhandled exception: page fault on read access to 0x0000000000000008 in 64-bit code (0x006fffff045a63). =>0 0x006fffff045a63 _FindAndUnlinkFrame+0x53(fi=000000000010C5B0) in ucrtbase (0x0000000010c5f0) 1 0x006fffff045a63 __CxxUnregisterExceptionObject+0xa3(frame_info=<internal error>, in_use=<is not available>) in ucrtbase (0x0000000010c5f0) 2 0x006ffffe5529e2 cxx_catch_cleanup+0x12(normal=<has been optimized away by compiler>, c=<is not available> and I find only one (still strange) occurence of 'Unhandled attr op: 2' so basically, it could well be there are three different issues to consider: - the crash in dbghelp when reading dinput8.dll seems to be gone (I'll upstream the relevant patches) (note: that dbghelp is loaded both by supertux2 when setting up its crashhandler and capture backtrace, and winedbg when debugging supertux2) - there's an exception generated (running without winedbg, with WINEDEBUG=+seh,+unwind could help to get some idea where it comes from) - then exception is caught by supertux2 exception handler, and its processing causes another crash (likely in ucrtbase) (it has yet to be defined where the issue comes from) potentially it may be needed to open different tickets for the last two points (as they likely impact different components); but let start by looking at WINEDEBUG=+seh,+unwind output TIA -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #16 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Created attachment 81426 --> http://bugs.winehq.org/attachment.cgi?id=81426 WINEDEBUG=+seh,+unwind output -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60004 --- Comment #17 from Tobias (:Tobbi) Markus <tobbi.bugs@googlemail.com> --- Any updates on this? -- 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