[Bug 56829] New: Program Crashes Unexpectedly After Updating Wine Version from WineHQ Repository
https://bugs.winehq.org/show_bug.cgi?id=56829
Bug ID: 56829 Summary: Program Crashes Unexpectedly After Updating Wine Version from WineHQ Repository Product: Wine Version: 8.0.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: csumushu@126.com Distribution: ---
“When I installed Wine 8.0 from the Ubuntu software source on Ubuntu 23.10, the program worked fine. However, after switching to WineHQ’s repository and updating to Wine 9.0 on Ubuntu 23.10, the same program crashed due to an assert error when running with Wine. Interestingly, installing Wine 9.0 from the Ubuntu software source on Ubuntu 24.04 works without any issues. What could be the reason for this?”
The following is the error when running in the Wine 9.0 environment on Ubuntu 23.10.
root@mushu:~/osn8800# WINEDEBUG=fixme-all wine64 winosp_release/winospexe/winosp.exe "C:\ProgramData\ne1\WINOSPHARDCFG.INI" 02a0:err:msvcrt:_wassert (L"!sig_type || sig_type->tag == SymTagFunctionType",L"dlls/dbghelp/symbol.c",329)
https://bugs.winehq.org/show_bug.cgi?id=56829
mushu csumushu@126.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|8.0.1 |9.0
https://bugs.winehq.org/show_bug.cgi?id=56829
--- Comment #1 from mushu csumushu@126.com --- Installing Wine from the WineHQ repository shows the version as 9.0 when using the wine --version command, while installing Wine from the Ubuntu repository shows the version as 9.0~repack-4build3 with the same command. What is the difference between them?
https://bugs.winehq.org/show_bug.cgi?id=56829
--- Comment #2 from mushu csumushu@126.com --- Created attachment 76637 --> https://bugs.winehq.org/attachment.cgi?id=76637 log file
https://bugs.winehq.org/show_bug.cgi?id=56829
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com
--- Comment #3 from Eric Pouech eric.pouech@gmail.com --- Two questions: - is the winosp program freely available somewhere? - can you attach the output of running with WINEDEBUG=+dbghelp_symt (compressed, could be huge)
TIA
https://bugs.winehq.org/show_bug.cgi?id=56829
--- Comment #4 from mushu csumushu@126.com --- the `winosp` program is not freely available online. the log file is attached.
There is a strange issue. If I run the program with WINEDEBUG=fixme-all,+dbghelp_symt or WINEDEBUG=dbghelp_symt, the program exits quickly. I can’t find the assertion in the logs, and two windows pop up: one titled ‘wine debugger’ and the other ‘program error.’ However, if I run the program with WINEDEBUG=fixme-all, only the assertion log appears.
https://bugs.winehq.org/show_bug.cgi?id=56829
--- Comment #5 from mushu csumushu@126.com --- (In reply to Eric Pouech from comment #3)
Two questions:
- is the winosp program freely available somewhere?
- can you attach the output of running with WINEDEBUG=+dbghelp_symt
(compressed, could be huge)
TIA
I’m very sorry, but due to company network restrictions, I cannot upload the log file. Are there any keywords I can look for?
https://bugs.winehq.org/show_bug.cgi?id=56829
--- Comment #6 from Eric Pouech eric.pouech@gmail.com ---
I’m very sorry, but due to company network restrictions, I cannot upload the log file. Are there any keywords I can look for?
there are three different things you could try: 1) rerun the program with WINEDEBUG=+dbghelp,+dbghelp_symt,+dbghelp_dwarf,+dbghelp_msc,+seh in the generated log file, find out either: - there should be traces about launching winedbg or triggering - locate the exception (seh) before that and share the location of the crash - locate the dbghelp SymLoadModule* trace before that and share that information 2) in the window that pops named winedbg, can you actually copy the backtrace that appears? (you can limit that to the frames corresponding to wine components) 3) are there in the application directory (and/or its subdirectories) named *.pdb? if so, it would be interesting to rerun the program without these files (ie move them outside of the app dir - of course remembering where they were and put them back in place afterwards)
https://bugs.winehq.org/show_bug.cgi?id=56829
--- Comment #7 from Eric Pouech eric.pouech@gmail.com --- crash is similar as the one reported in [1] hard to tell without more info if the cause is the same
[1] https://bugs.winehq.org/show_bug.cgi?id=56577
https://bugs.winehq.org/show_bug.cgi?id=56829
--- Comment #8 from mushu csumushu@126.com --- (In reply to Eric Pouech from comment #6)
I’m very sorry, but due to company network restrictions, I cannot upload the log file. Are there any keywords I can look for?
there are three different things you could try:
- rerun the program with
WINEDEBUG=+dbghelp,+dbghelp_symt,+dbghelp_dwarf,+dbghelp_msc,+seh in the generated log file, find out either:
- there should be traces about launching winedbg or triggering
- locate the exception (seh) before that and share the location of the crash
- locate the dbghelp SymLoadModule* trace before that and share that
information 2) in the window that pops named winedbg, can you actually copy the backtrace that appears? (you can limit that to the frames corresponding to wine components) 3) are there in the application directory (and/or its subdirectories) named *.pdb? if so, it would be interesting to rerun the program without these files (ie move them outside of the app dir - of course remembering where they were and put them back in place afterwards)
Method 3 can solve the problem. Why is that so?
https://bugs.winehq.org/show_bug.cgi?id=56829
--- Comment #9 from Eric Pouech eric.pouech@gmail.com ---
Method 3 can solve the problem. Why is that so?
these .pdb files contain symbolic debug information, which are loaded by dbghelp likely something goes wrong it this process
-
WineHQ Bugzilla