https://bugs.winehq.org/show_bug.cgi?id=48274
Bug ID: 48274 Summary: Initialization of wineprefix failed Product: Wine Version: 4.21 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: rmkk@atlas.cz
Created attachment 65944 --> https://bugs.winehq.org/attachment.cgi?id=65944 Terminal output of failed wineprefix initialization
Wine-staging was installed including 64-bit support, then I tried to initialize new wine prefix with errors, terminal output included
https://bugs.winehq.org/show_bug.cgi?id=48274
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #1 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 65952 --> https://bugs.winehq.org/attachment.cgi?id=65952 Patch reverts commits to avoid regression wine-staging 4.21
https://bugs.winehq.org/show_bug.cgi?id=48274
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Product|Wine |Wine-staging Component|-unknown |-unknown Summary|Initialization of |Regression - wine-staging |wineprefix failed |4.21 fails to initialize | |wineprefix (shared wow64 | |build - 64-bit thunk) Severity|blocker |major Regression SHA1| |5fbf201ea8b61b09540905a98fa | |edfe3ab15e0bd Ever confirmed|0 |1 CC| |leslie_alistair@hotmail.com | |, z.figura12@gmail.com Status|UNCONFIRMED |NEW
--- Comment #2 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Thanks for reporting the issue.
Confirming the issue.
I have it too since 4.21 release. Only affects shared wow64 build of wine-staging.
Reducing severity to major.
Regression test shows that the regression is in winebuild-Fake_Dlls/0010-tools-winebuild-Add-syscall-thunks-for-64-bit.patch
Reverting wine-staging commits 5fbf201 and 0c89d96 make wine-staging usable again.
The attached patch makes wine-staging usable again.
$ gcc --version gcc (Debian 4.9.2-10+deb8u2) 4.9.2
Debian 8 jessie amd64.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- It works fine here. It might be a Mac-specific issue, though I can't guess why.
https://bugs.winehq.org/show_bug.cgi?id=48274
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Regression - wine-staging |wine-staging 4.21 fails to |4.21 fails to initialize |run 64-bit programs |wineprefix (shared wow64 | |build - 64-bit thunk) | Hardware|x86 |x86-64
https://bugs.winehq.org/show_bug.cgi?id=48274
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #4 from Paul Gofman gofmanp@gmail.com --- (In reply to Olivier F. R. Dierick from comment #2)
The attached patch makes wine-staging usable again.
$ gcc --version gcc (Debian 4.9.2-10+deb8u2) 4.9.2
Debian 8 jessie amd64.
I cannot reproduce it too, neither with my local build nor with winehq build for Fedora.
Can you please confirm if just replacing <winebin>/lib64/wine/ntdll.so in the "bad" build with the one from "good" build (with the refenced patches reversed) fixes the issue? Could you please also attach that 64 bit ntdll.so binary from your "bad" build and specify which exactly flags are used for building?
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #5 from Paul Gofman gofmanp@gmail.com --- Also, could you please attach WINEDEBUG=+seh,+module,+thread,+process log?
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #6 from radim rmkk@atlas.cz --- Created attachment 65956 --> https://bugs.winehq.org/attachment.cgi?id=65956 Debug log from macos as requested
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #7 from Paul Gofman gofmanp@gmail.com --- (In reply to radim from comment #6)
Created attachment 65956 [details] Debug log from macos as requested
Thanks, could you please also attach ntdll.dll.so from <wine install dir>/lib64/wine? Or is it maybe .dylib instead of .so? I am sorry, I don't have Macos and never did anything with it.
As I understood the problem happens on Debian 8 jessie too, so the information from Debian I asked about in comments #4, #5 could still be much helpful.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #8 from radim rmkk@atlas.cz --- Created attachment 65957 --> https://bugs.winehq.org/attachment.cgi?id=65957 ntdll.dll.so
ntdll.dll.so comes from directory: /Users/radim/Applications/Wine Staging.app/Contents/Resources/wine/lib64/wine
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #9 from Paul Gofman gofmanp@gmail.com --- Created attachment 65958 --> https://bugs.winehq.org/attachment.cgi?id=65958 force stack alignment in syscall dispatcher
Looks like syscall thunks violate stack alignment.
The segfaulting instruction in NtQuerySystemInformation is like this:
vmovaps %xmm6,0x1090(%rsp)
This is aligned 16-byte SSE register load which segfaults on most CPUs if the actual address is unaligned.
The "good" builds have explicit stack alignments in functions' prologues:
-- 7bcad2e1: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 7bcad2e5: 48 81 ec 90 10 00 00 sub $0x1090,%rsp 7bcad2ec: c7 84 24 40 01 00 00 movl $0x0,0x140(%rsp) 7bcad2f3: 00 00 00 00 7bcad2f7: c5 f8 29 b4 24 90 10 vmovaps %xmm6,0x1090(%rsp) --
The library attached in the previous comment does not have an alignment but is still using the same aligned stores / loads, assuming x64 ABI which requires rsp + 8 to be 16 bytes aligned on function entry.
Does the attached patch help?
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #10 from radim rmkk@atlas.cz --- myself I cannot check if given patch help or no, because I not able to compile, deploy etc, sorry, probably it is not an easy task, is it ?
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #11 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 65966 --> https://bugs.winehq.org/attachment.cgi?id=65966 Terminal output - ntdll.dll.so replaced with "good" one - binary mismatch
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #12 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 65967 --> https://bugs.winehq.org/attachment.cgi?id=65967 "bad" ntdll.dll.so - compiled on debian 8 jessie amd64
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #13 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 65968 --> https://bugs.winehq.org/attachment.cgi?id=65968 wine-staging 4.21 build log of 64-bit part (3.4MB uncompressed)
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #14 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 65969 --> https://bugs.winehq.org/attachment.cgi?id=65969 wine-staging 4.21 "bad" +seh,+module,+thread,+process terminal output.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #15 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 65970 --> https://bugs.winehq.org/attachment.cgi?id=65970 wine-staging 4.21-your patch +seh,+module,+thread,+process terminal output.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #16 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
(In reply to Paul Gofman from comment #4)
Can you please confirm if just replacing <winebin>/lib64/wine/ntdll.so in the "bad" build with the one from "good" build (with the refenced patches reversed) fixes the issue? Could you please also attach that 64 bit ntdll.so binary from your "bad" build and specify which exactly flags are used for building?
Replacing ntdll.dll.so with "good" one results in a binary mismatch. I don't know how to avoid that.
I use 'configure' options --enable-win64, --prefix and --without-* for a few libraries missing from debian 8 jessie, and 'make' option -j and no option for 'make install'. I don't use custom build flags.
Attached replacement log, "bad" ntdll.dll.so and shared wow 64-bit part build log.
(In reply to Paul Gofman from comment #5)
Also, could you please attach WINEDEBUG=+seh,+module,+thread,+process log?
(In reply to Paul Gofman from comment #9)
Does the attached patch help?
It goes further and create a partial wineprefix but also fails.
I attached the requested log for "bad" and then "bad" + comment 9 patch.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #17 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- I forgot to compress ntdll.dll.so, sorry for the inconvenience.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #18 from Paul Gofman gofmanp@gmail.com --- (In reply to Olivier F. R. Dierick from comment #16)
Hello,
(In reply to Paul Gofman from comment #4)
Can you please confirm if just replacing <winebin>/lib64/wine/ntdll.so in the "bad" build with the one from "good" build (with the refenced patches reversed) fixes the issue? Could you please also attach that 64 bit ntdll.so binary from your "bad" build and specify which exactly flags are used for building?
Replacing ntdll.dll.so with "good" one results in a binary mismatch. I don't know how to avoid that.
The "binary mismatch" log says that the server version is different. I might not have been entirely clear, but by "good" build I meant the one which is the same as "bad" but with the blamed patch not there. The blamed patch is not changing the server version. But I don't think it makes much sense to spend time getting back to that now, I asked for that before I saw any logs / failing binaries and that was meant like overall "sanity" check to make sure we are not missing something obvious.
It goes further and create a partial wineprefix but also fails.
I attached the requested log for "bad" and then "bad" + comment 9 patch.
At this point I got a bit lost. Your initial log and binary (without my patch) shows exactly the same problem as in MacOS build. Now with the patch applied it gets a error much earlier, now without any crash or specific error indication. I don't yet see how it is possible. E. g., if my patch would screw up stack / arguments access I don't see how it would not be reproducible on my builds. Please don't get me wrong, I am not saying that you necessarily mixed up something here, but I lost the track with these results and am tempted to suspect first that something is wrong with the patched build in some completely new way.
The patch has now been included in Staging 5-0rc1. May I ask you to retest with the clean 5.0rc1 build and prefix, and if it still doesn't work, attach the log with +seh,+module,+thread,+process,+loaddll,+imports?
Thanks for testing this.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #19 from Radim Kolek rmkk@atlas.cz --- Created attachment 65995 --> https://bugs.winehq.org/attachment.cgi?id=65995 Debug log from wine-5.0-rc1
... 000b:trace:module:MODULE_InitDLL (0x71040000,PROCESS_ATTACH,0x31fb00) - RETURN 0 000b:trace:module:MODULE_InitDLL (0x71040000 L"kernelbase.dll",PROCESS_DETACH,0x31fb00) - CALL 000b:trace:module:MODULE_InitDLL (0x71040000,PROCESS_DETACH,0x31fb00) - RETURN 1 000b:warn:module:process_attach Initialization of L"kernelbase.dll" failed ...
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #20 from Paul Gofman gofmanp@gmail.com --- (In reply to Radim Kolek from comment #19)
Created attachment 65995 [details] Debug log from wine-5.0-rc1
This log is different and now it seems to pass kernel32 initialization and crashes in kernelbase initialization. Could you please attach the 64 binaries for ntdll.dll.so and kernelbase.dll which you've got now with wine-5.0-rc1?
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #21 from Radim Kolek rmkk@atlas.cz --- Created attachment 65996 --> https://bugs.winehq.org/attachment.cgi?id=65996 64bit_binaries_wine-5.0-rc1.zip
https://bugs.winehq.org/show_bug.cgi?id=48274
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #65958|0 |1 is obsolete| |
--- Comment #22 from Paul Gofman gofmanp@gmail.com --- Created attachment 65997 --> https://bugs.winehq.org/attachment.cgi?id=65997 force stack alignment in syscall dispatcher
Oh well, it is actually about all the same crash in issue which my initial patch failed to fix properly. At least the one related to MacOS, the new logs for Debian look unrelated.
Sadly I cannot reproduce the issue to test it properly, though yet of course I could be more attentive regardless. I entirely missed the fact that the stack pointer is updated for copying on stack arguments after my added alignment. That is probably the reason why patch did not help.
I am attaching the updated patch (on top of current Wine Staging) which is hopefully fixing it now properly.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #23 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
(In reply to Olivier F. R. Dierick from comment #16)
Replacing ntdll.dll.so with "good" one results in a binary mismatch.
This was a user error, sorry. I know it is kind of useless now but I had to retest to understand what I did wrong to avoid future binary mismatch.
After fixing that, replacing ntdll.dll.so with "good" makes "bad" staging 4.21 work again.
(In reply to Paul Gofman from comment #22)
I am attaching the updated patch (on top of current Wine Staging) which is hopefully fixing it now properly.
wine-staging 5.0-rc1 + attachment 65997 fixes the issue for me.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48274
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #65966|0 |1 is obsolete| |
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #24 from Paul Gofman gofmanp@gmail.com --- (In reply to Olivier F. R. Dierick from comment #23)
wine-staging 5.0-rc1 + attachment 65997 [details] fixes the issue for me.
Thanks for testing & confirming. The fix has been pushed to Staging. The issue looks exactly the same in MacOS build, so there are not much reasons to doubt it will fix that too.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #25 from Radim Kolek rmkk@atlas.cz ---
The fix has been pushed to Staging.
Staging downloaded now includes files with 14.12.2019 timestamp, so I expect that fix was not merged yet. So I'll try it sometimes in the future.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #26 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Radim Kolek from comment #25)
The fix has been pushed to Staging.
Staging downloaded now includes files with 14.12.2019 timestamp, so I expect that fix was not merged yet. So I'll try it sometimes in the future.
Hello,
The fix was added to wine-staging GIT yesterday 2019-12-16. It'll be released in 5.0-rc2 at the end of this week.
commit d36d63ac848dadbc2c8ffc933f7c044aa86b6d41.
https://github.com/wine-staging/wine-staging/commit/d36d63ac848dadbc2c8ffc93...
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48274
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #27 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Fixed for me in 5.0-rc2.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #28 from Radim Kolek rmkk@atlas.cz --- Can't confirm yet, 5.0-rc2 build is not available for macos.
https://bugs.winehq.org/show_bug.cgi?id=48274
--- Comment #29 from Radim Kolek rmkk@atlas.cz --- Fixed on MACOS in 5.0-rc2. Thanks.
https://bugs.winehq.org/show_bug.cgi?id=48274
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #30 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Fixed wine-staging.