[Bug 57386] New: Attempting to run The Sims 1 Complete Collection results in a loop in dbghelp.
https://bugs.winehq.org/show_bug.cgi?id=57386 Bug ID: 57386 Summary: Attempting to run The Sims 1 Complete Collection results in a loop in dbghelp. Product: Wine Version: 9.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dbghelp Assignee: wine-bugs(a)winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- I'm assuming the game crashed for some reason, but attempting to run The Sims 1 Complete Collection results in no game window being made, and the following message echoed to the console indefinitely until the game process is killed: fixme:dbghelp:elf_search_auxv can't find symbol in module Running with WINEDEBUG=+dbghelp shows that it's trying to load debugging symbols but fails when it tries to load the symbol for ntdll.so!main_envp: 0120:trace:dbghelp:SymFromName (FFFFFFFF, "ntdll.so!main_envp", 0080E378) 0120:trace:dbghelp:image_locate_build_id_target checking L"/usr/lib/debug/.build-id/90/0892727821433d4332b9bd84b5d49ad3e0735b.debug" 0120:trace:dbghelp:image_locate_build_id_target checking \??\Z:\home\ADS.CODENET\codebase\.cache\debuginfod_client\900892727821433d4332b9bd84b5d49ad3e0735b\debuginfo 0120:trace:dbghelp:image_locate_build_id_target not found 0120:trace:dbghelp:image_load_debugaltlink No .gnu_debugaltlink section found for L"ntdll.so" 0120:fixme:dbghelp:elf_search_auxv can't find symbol in module -- 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=57386 --- Comment #1 from Rafał Mużyło <galtgendo(a)o2.pl> --- ...that message is kinda meaningless wrt. *why* the crash did happen. So, what was the earlier 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.
https://bugs.winehq.org/show_bug.cgi?id=57386 --- Comment #2 from Patrick Hibbs <hibbsncc1701(a)gmail.com> --- Created attachment 77358 --> https://bugs.winehq.org/attachment.cgi?id=77358 Console log Default console log. -- 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=57386 --- Comment #3 from Patrick Hibbs <hibbsncc1701(a)gmail.com> --- Created attachment 77359 --> https://bugs.winehq.org/attachment.cgi?id=77359 WINEDEBUG=+dbghelp log. Log with WINEDEBUG=+dbghelp. -- 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=57386 --- Comment #4 from Patrick Hibbs <hibbsncc1701(a)gmail.com> --- For some additional info, I've confirmed that using `winetricks dbghelp` is a valid workaround. (Although it won't prevent the game from crashing, it will allow the game to terminate like it's supposed to.) -- 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=57386 --- Comment #5 from Rafał Mużyło <galtgendo(a)o2.pl> --- OK, I've misread your initial report. Your main problem isn't that the game crashes, but that during the crash it goes into a loop, where it repeatedly calls dbghelp. That's actually somewhat interesting. The message itself still is likely meaningless - it's just a standard notice that your version of wine was stripped of debug symbols. Interesting part is that (if I'm reading it correctly) the game is shipped with its debug symbols in pdb files and dbghelp tries to load those. Hmmm..., here's an idea: if you temporarily move those pdb files from their current location, does it crash in the same place, but without going into a loop ? -- 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=57386 --- Comment #6 from Patrick Hibbs <hibbsncc1701(a)gmail.com> --- (In reply to Rafał Mużyło from comment #5)
OK, I've misread your initial report.
No biggie.
Hmmm..., here's an idea: if you temporarily move those pdb files from their current location, does it crash in the same place, but without going into a loop ?
The game doesn't ship with any pdb files. Doing a 'find </path/to/game/dir> -regex .*\.pdb' yields no results, and doing an ls for the named file in the log results in a no such file or directory message. -- 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=57386 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech(a)gmail.com --- Comment #7 from Eric Pouech <eric.pouech(a)gmail.com> --- from a cursory look in #3: - loading dbghelp by game to instrospect itself - first bulk made of: + SymInitialize() + SymLoadModule (from process) + StackWalk (produces 10 frames or so) + SymCleanup() - second bulk made of: + SymInitialize() + SymLoadModule (from process) + StackWalk (*** here fails at first frame ***) + SymCleanup() - third bulk made of: + SymInitialize() + SymLoadModule (from process), interrupted by user hard to get definite answers from that, but the failing StackWalk in second bulk should be the first thing to look at I'm only aware of an existing issue in i386 unwinding code. Could you post the output of running this command
winedump -x <file> | grep -i fpo for each <file> as sims.exe, gimexrtz.dll, ijl10.dll if by any luck that's the same issue
-- 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=57386 --- Comment #8 from Patrick Hibbs <hibbsncc1701(a)gmail.com> --- (In reply to Eric Pouech from comment #7)
from a cursory look in #3: - loading dbghelp by game to instrospect itself - first bulk made of: + SymInitialize() + SymLoadModule (from process) + StackWalk (produces 10 frames or so) + SymCleanup() - second bulk made of: + SymInitialize() + SymLoadModule (from process) + StackWalk (*** here fails at first frame ***) + SymCleanup() - third bulk made of: + SymInitialize() + SymLoadModule (from process), interrupted by user
hard to get definite answers from that, but the failing StackWalk in second bulk should be the first thing to look at
I'm only aware of an existing issue in i386 unwinding code. Could you post the output of running this command
winedump -x <file> | grep -i fpo for each <file> as sims.exe, gimexrtz.dll, ijl10.dll if by any luck that's the same issue
Still present in Wine-10.2. Sorry for taking so long to get back to this. Honestly, I forgot about it.... The output you requested is blank. I.e: /Maxis/The Sims$ for i in Sims.exe gimex.dll ijl10.dll; do winedump -x "${i}" | grep -i fpo; done; /Maxis/The Sims$ There is a change however in current behavior. As of Wine-10.2 this bug seems to be intermittent. I've only been able to get it to occur reliably under some older (read: slower) hardware. Not sure if that helps any, but I figured I'd mention it. -- 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