https://bugs.winehq.org/show_bug.cgi?id=40502
Bug ID: 40502 Summary: Global objects constructors fail when invoking standard libs Product: Wine Version: 1.8.1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: winelib Assignee: wine-bugs@winehq.org Reporter: mirko.ortensi@gmail.com Distribution: ---
I managed to recompile and link my win32 application but at execution time, it crashes because of a segmentation fault where memset (or the bare printf("HELLO")) is invoked in the global object constructor (any call to standard C library is enough to trigger the crash).
The global object is built in the stack, then it seems that at launch time my object constructor is called before C Standard Library is ready. Now, as a workaround I can declare a pointer to global object and instantiate it in the main (tested, it works)...though...this is something I'd like to avoid to keep the code as original as possible. Removing the global objects, everything works like a charm.
As far as I understand, global object constructors are called after Wine infrastructure is ready to go, though I have doubts now regarding C Standard Library. (Please check 8.3.3. Starting a Winelib process https://www.winehq.org/docs/winedev-guide/x3172)
This code reproduces the error:
#include <stdio.h>
class Printer { public: Printer(){printf("HI\n");} };
Printer p;
int main(void) { return 0; }
The issue is reproduced by this code linking to msvcrt: wineg++ -mno-cygwin issue.cpp -o issue
Linking to system libs, this code does not reproduce the issue. wineg++ issue.cpp -o issue
Now, in my code (pretty big software I am porting to Linux) I still need to isolate root cause, issue is reproduced even linking against system libraries (not Wine's msvcrt, then). Anyway, I think there's a bug somewhere when linking to msvcrt even in this silly piece of code.
https://bugs.winehq.org/show_bug.cgi?id=40502
--- Comment #1 from mirko.ortensi@gmail.com --- Please consider also that this issue has been described here as well: https://www.winehq.org/pipermail/wine-devel/2015-August/108903.html
https://bugs.winehq.org/show_bug.cgi?id=40502
--- Comment #2 from Mirko Ortensi mirko.ortensi@gmail.com --- Follows gdb backtrace
Program terminated with signal 11, Segmentation fault. #0 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0xb6417798 in Printer::Printer (this=0xb641fbe0) at issue.cpp:16 #2 0xb6417748 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at issue.cpp:20 #3 0xb6417770 in _GLOBAL__sub_I_issue.cpp(void) () at issue.cpp:42 #4 0xb6ee9220 in ?? () from /lib/ld-linux-armhf.so.3 #5 0x00f4d988 in ?? () #6 0x00f4d988 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?)
https://bugs.winehq.org/show_bug.cgi?id=40502
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC| |nerv@dawncrow.de
--- Comment #3 from André H. nerv@dawncrow.de --- I tried to have a closer look... What happens is that the file gets dlopen'ed and crashes at that point. This might either be due to dependency problems or maybe the constructor setup code is called and something is horribly wrong there... I guess there's some work to do in winebuild and/or winecrt0
https://bugs.winehq.org/show_bug.cgi?id=40502
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED CC| |jacek@codeweavers.com
--- Comment #4 from André H. nerv@dawncrow.de --- I talked about this with Jacek yesterday and tried it myself again today and noticed it is fixed meanwhile.
https://bugs.winehq.org/show_bug.cgi?id=40502
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |---
--- Comment #5 from André H. nerv@dawncrow.de --- (In reply to André H. from comment #4)
I talked about this with Jacek yesterday and tried it myself again today and noticed it is fixed meanwhile.
I did it wrong, with -mno-cygwin it still crashes
https://bugs.winehq.org/show_bug.cgi?id=40502
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@twig.hk
--- Comment #6 from Fabian Maurer dark.shadow4@web.de --- *** Bug 48875 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=40502
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #7 from Fabian Maurer dark.shadow4@web.de --- Still an issue as of wine-5.5.
When the program is loaded, during wine_dlopen, the static constructors are run. But only during main, wine gets a chance to fixup the imports by calling LdrInitializeThunk.
So during static constructors no wine code can be called, since the imports are not fixed up yet.
https://bugs.winehq.org/show_bug.cgi?id=40502
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- This should work now.
https://bugs.winehq.org/show_bug.cgi?id=40502
--- Comment #9 from André H. nerv@dawncrow.de --- yes, the test from #c0 works here
https://bugs.winehq.org/show_bug.cgi?id=40502
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.7.