https://bugs.winehq.org/show_bug.cgi?id=56101
Bug ID: 56101 Summary: Cheat Engine 7.5 (32bit) crashes shorty after attaching to process Product: Wine Version: 8.21 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: dark.shadow4@web.de Distribution: ---
Originally reported at https://forum.winehq.org/viewtopic.php?t=38340
This is a regression introduced by wine-8.10. Shortly after attachign to a process (e.g. notepad.exe) Cheat Engine crashes. Tried in 32bit WINEPREFIX.
https://bugs.winehq.org/show_bug.cgi?id=56101
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://d1vdn3r1396bak.clou | |dfront.net/installer/581759 | |28/04514669833227688
https://bugs.winehq.org/show_bug.cgi?id=56101
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- It works for me using the Arch Linux package wine-8.9, but compiling from source makes it not work again. Unless I compile with -O2
Okay, this is worse than I thought: - Arch Linux Packages: wine-8.10 broken, wine-8.9 works - From source: 8.9 and 8.10 broken, unless compiled with -O2. With -O2, 8.10 works as well
https://bugs.winehq.org/show_bug.cgi?id=56101
--- Comment #2 from Fabian Maurer dark.shadow4@web.de --- And now it doesn't work at all when compiling from source. Something is pretty wrong here, but I currently can't figure it out.
https://bugs.winehq.org/show_bug.cgi?id=56101
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=56101
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #3 from Bernhard Übelacker bernhardu@mailbox.org --- I did also a little testing:
- I got a crash also with wine-8.9 or wine-8.1. (winehq bookworm packages)
- Cheat Engine 7.4 shows does not crash with current wine-9.0-rc3 (self built) (https://github.com/cheat-engine/cheat-engine/releases/tag/7.4)
- After having 7.4 once attached to a process, 7.5 did also no longer crash, except one removes again: "c:/users/benutzer/Temp/Cheat Engine Symbols/structures.sqlite"
https://bugs.winehq.org/show_bug.cgi?id=56101
--- Comment #4 from Fabian Maurer dark.shadow4@web.de --- Problem seems to be a SymGetTypeInfo call that gets passed a "handle" that is complemently invalid, it looks more like a pointer. Therefore the functions returns false and the program crashes later on. In fact, the other function parameters don't seem valid either. Maybe that's due to some stack corruption...? Native dbghelp helps, so that dll is most likely where the problem is.
Since CheatEngine is open source we can have a look at its code. It seems to start here with SymEnumTypes: https://github.com/cheat-engine/cheat-engine/blob/464b07e7bc83191307975013f9... Then it calls into SymGetTypeInfo: https://github.com/cheat-engine/cheat-engine/blob/464b07e7bc83191307975013f9...
FWIW, it crashes even sooner with the new wow64. Not sure why, but in CheatEngine7.4 SymEnumTypes isn't called and so there is no crash.
https://bugs.winehq.org/show_bug.cgi?id=56101
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com --- I don't know if it matters, but they don't have SymGetTypeInfo marked as stdcall, and most or all other functions are marked like that.
https://bugs.winehq.org/show_bug.cgi?id=56101
--- Comment #6 from Fabian Maurer dark.shadow4@web.de --- Good catch, I missed that. However, even making the function as cdecl in wine doesn't change it. I might try to recompile the program itself to doublecheck.
https://bugs.winehq.org/show_bug.cgi?id=56101
--- Comment #7 from Nikolay Sivov bunglehead@gmail.com --- I think obj-pascal might be using something else by default that's neither stdcall nor cdecl, so yes, if only to verify it makes sense to rebuild the test program itself.
Is it possible this path is never taken on normal execution, on Windows, or on with native dbghelp, for whatever reason?
https://bugs.winehq.org/show_bug.cgi?id=56101
--- Comment #8 from Fabian Maurer dark.shadow4@web.de ---
Is it possible this path is never taken on normal execution, on Windows, or on with native dbghelp, for whatever reason?
Seems at least plausible, although I don't really know how to verify that without breaking cleanroom guidelines.
https://bugs.winehq.org/show_bug.cgi?id=56101
--- Comment #9 from Fabian Maurer dark.shadow4@web.de --- EDIT: of course, when I manage to compile the testprogram I could add some extra logging to check if the path is taken or not
https://bugs.winehq.org/show_bug.cgi?id=56101
--- Comment #10 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 75802 --> https://bugs.winehq.org/attachment.cgi?id=75802 notes, backtraces with debug symbols and modifications.txt
I did some testing and got a cheatengine-i386.exe built with debug symbols. There I found the crash happens because the return address on top of the stack got overwritten with zero and therefore after the ret instructions the crash happens when address 0 is executed.
Further a cheatengine-i386.exe with additional writeln's showed that on windows the SymEnumTypes is called, no SymGetTypeInfo (targetting a wine notepad.exe).
A cheatengine-i386.exe with the "stdcall;" added to the SymGetTypeInfo definition did no longer crash in wine.
I assume wine's dbghelp.dll is able to read the debug information in wine's dlls. Native dlls and cheatengine-i386.exe might have stripped those away, or use a format not understood by native dbghelp.dll?
I tried to bring this to the Cheat Engine's developers here: https://github.com/cheat-engine/cheat-engine/issues/2789
https://bugs.winehq.org/show_bug.cgi?id=56101
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|NEW |RESOLVED Keywords|regression |
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Not our bug then, and not a regression.