https://bugs.winehq.org/show_bug.cgi?id=51596
Bug ID: 51596 Summary: Unhandled exception code c0000005 when running any 64-bit Winelib application Product: Wine Version: 6.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winelib Assignee: wine-bugs@winehq.org Reporter: mail@robbertvanderhelm.nl Distribution: ArchLinux
Somewhere after Wine 6.14, 64-bit Winelib applications are no longer able to start when Wine is compiled with optimizations. Everything still works just fine when setting {C,CXX,CROSSC}FLAGS to "-g -O0", and 32-bit Winelib applications also still work fine. I haven't tested which exact commit introduced this issue, but it at least happens after f63ecaedc72f3580e7016ba71a480025e4d86e99
To reproduce this issue, create a main.cpp file with the following contents and then compile it with `wineg++ -o main main.cpp -mwindows -m64`:
#include <iostream>
int main() { std::cout << "Hello, world!" << std::endl; }
Running main.exe with these versions of the latest master branch version of Wine Staging (wine-6.14-323-g91494ae6f2e right now) prints the following:
0144:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x7bc2dc17
Doing the same thing with a 32-bit Winelib (i.e. with -m32) works just fine, and the 64-bit version also works fine when compiling Wine the following configuration:
CC='ccache gcc' CXX='ccache g++' CROSSCC='ccache x86_64-w64-mingw32-gcc' CFLAGS="-g -O0" CXXFLAGS="-g -O0" CROSSCFLAGS="-g -O0" ../configure --disable-tests --enable-win64
Leaving out those flags brings back the error, so there's likely some kind of UB at play here.
https://bugs.winehq.org/show_bug.cgi?id=51596
--- Comment #1 from Robbert van der Helm mail@robbertvanderhelm.nl --- Apparently this does not affect applications compiled with winegcc. Only C++ code compiles with Wineg++ is affected by this. The C-equivalent compiles and runs just fine:
#include <stdio.h>
int main() { printf("Hello, world!\n"); }
https://bugs.winehq.org/show_bug.cgi?id=51596
Robbert van der Helm mail@robbertvanderhelm.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|6.14 |6.15 Regression SHA1| |e5339ecbc66f20193a0a6b1dfdc | |e98d42d2ad926
https://bugs.winehq.org/show_bug.cgi?id=51596
Scott Garman sgarman@zenlinux.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sgarman@zenlinux.com
https://bugs.winehq.org/show_bug.cgi?id=51596
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #2 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 70490 --> https://bugs.winehq.org/attachment.cgi?id=70490 Details on the debugging attempt.
I tried to debug this and think I found some details.
In function "init_builtin_dll" an array with init functions is queried and called afterwards.
Unfortunately the base address of this array is stored in register $rsi, which gets overwritten in the call to the function frame_dummy/register_tm_clones (main.exe).
I tried adding a "volatile" to the variable funcs declaration, and with that the executable did output its message without crash.
- void (**funcs)(int, char **, char **) = (void *)buffer; + void (** volatile funcs)(int, char **, char **) = (void *)buffer;
Unfortunately I can't tell if $rsi is allowed to be overwritten at that point and wineg++ has to be modified to avoid this, or if the "volatile" approach is right (and reliable).
https://bugs.winehq.org/show_bug.cgi?id=51596
--- Comment #3 from Robbert van der Helm mail@robbertvanderhelm.nl --- @bernhardu It's the calling conventions not matching up. Openglfreak submitted a patch for it a couple of days ago: https://www.winehq.org/pipermail/wine-devel/2021-August/192651.html
https://bugs.winehq.org/show_bug.cgi?id=51596
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, patch, | |regression, source
https://bugs.winehq.org/show_bug.cgi?id=51596
--- Comment #4 from Robbert van der Helm mail@robbertvanderhelm.nl --- Is there anything I could do to help with this? I'd love to have this working again. From what I've gathered yabridge users don't enjoy downgrading Wine Staging as much as I thought. ;)
If setting the correct calling convention on the PE-side is not the correct approach, what should be done instead? Should these initialization functions be called directly in the Unix library?
https://bugs.winehq.org/show_bug.cgi?id=51596
davidzavalla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |davidzavalla@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=51596
Andrzej Kilijański and3md@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |and3md@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=51596
Oskenso winehq@oskenso.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@oskenso.com
https://bugs.winehq.org/show_bug.cgi?id=51596
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |e9cfc97d46aaf39bc9c2a41b319 | |d3b3b358c0f04 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- Reverted in e9cfc97d46aaf39bc9c2a41b319d3b3b358c0f04. This will need more thought.
https://bugs.winehq.org/show_bug.cgi?id=51596
David Zavalla davidzavalla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|davidzavalla@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=51596
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.18.