https://bugs.winehq.org/show_bug.cgi?id=52396
Bug ID: 52396 Summary: Stack overflows when running 64-bit .net6 program Product: Wine Version: 7.0-rc5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: matdug1@hotmail.com Distribution: ---
Created attachment 71635 --> https://bugs.winehq.org/attachment.cgi?id=71635 Sample project and steps to reproduce video
I'm seeing multiple instances of stack overflow errors when running 64 bits dotnet6 programs in Wine ( version 7.0 RC5 as well as in v6.0.2 Stable on Fedora )
The rationale for running a .net6 program in Wine instead of the native Linux implementation is that the Winform API is only supported in the Windows, Android and IOS versions of .net6. The app is also 64 bits because the debuggers for .net core (vsdbg, Samsung's netcoredbg) are apparently not available for windows in 32-bits flavors.
Included is a small .net6 application where the issue is easily reproduced.
STEPS TO REPRODUCE :
-Install the .net6 SDK from https://dotnet.microsoft.com/en-us/download/dotnet/6.0 on a Windows machine -Download the sample application WineStackOverflowError.zip -Build and publish the application :
dotnet publish WineStackOverflowError.csproj -r win7-x64
-Deploy the published app on Linux from .\bin\Debug\net6.0-windows\win7-x64\publish -Run the application in Wine -In the property grid click in rapid succession on the Backcolor field within the PropertyGrid. -After a few clicks a stack overflow error is triggered.
019c:err:virtual:virtual_setup_exception stack overflow 2704 bytes in thread 019c addr 0x1700540d9 stack 0x20570 (0x20000-0x21000-0x1a0000)
A webm video showing how to reproduce this is also provided.
Thank You
M. Dugal
https://bugs.winehq.org/show_bug.cgi?id=52396
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Ever confirmed|0 |1 CC| |xerox.xerox2000x@gmail.com Status|UNCONFIRMED |NEW URL| |https://dotnet.microsoft.co | |m/en-us/download/dotnet/6.0
--- Comment #1 from Louis Lenders xerox.xerox2000x@gmail.com --- Hi, thanks for bugreport.
Though I didn`t try the exact steps you provided, I can confirm this is in fact a problem with _any_ .Net Core 6 64-bit simple task/program you try to run (32-bit works ok)
I earlier tried to find the cause but couldn`t find it. Hopefully someone more proficient could have a look at this.
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #2 from Louis Lenders xerox.xerox2000x@gmail.com --- Just adding another very short way of reproducing error (from tutorial):
- wine dotnet-sdk-6.0.100-win-x86.exe
- wine dotnet new wpf -o MyApp
- cd MyApp
- wine dotnet run
A nice WPF window comes up (because here used 32-bit installer)
If you try the same with the 64-bit .net version it crashes (even the installer does not finish properly with the "err:virtual:virtual_setup_exception stack overflow"
https://bugs.winehq.org/show_bug.cgi?id=52396
M. Dugal matdug1@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |mscoree
https://bugs.winehq.org/show_bug.cgi?id=52396
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|mscoree |-unknown
--- Comment #3 from Louis Lenders xerox.xerox2000x@gmail.com --- Hi M. Dugal,
The mscoree component keyword is kind of reserved for Mono-bugs, which this apparently isn`t. so i`m setting back component to "unknown".
regards
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #4 from M. Dugal matdug1@hotmail.com --- Ok, thanks Louis
https://bugs.winehq.org/show_bug.cgi?id=52396
florian.will@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |florian.will@gmail.com
--- Comment #5 from florian.will@gmail.com --- I'm using the "dotnet dev-certs https" command to try and debug this, as it triggers the error and seems to be less multi-threaded/complex/long-running than other things I've attempted, and so I don't need to compile any dotnet executable myself.
According to "WINEDEBUG=+seh ./wine64 dotnet dev-certs https", it raises lots of code=0x02345678 exceptions, and then eventually ACCESS_VIOLATION exceptions, before the stack overflow happens. Apparently those 0x02345678 exceptions can be raised by the dotnet JIT compiler when it encounters invalid MSIL code ("InvalidProgramException"). Maybe this is also triggered on 64/32 bit mismatch when the dotnet runtime attempts to load native code from some DLL file, expecting it to be 32 bit but it turns out to be 64 bit, or vice versa? I honestly have no idea how that works. Or maybe something in wine makes the 64bit JIT compiler in dotnet6 believe that there is invalid MSIL code in managed executables files quite frequently.
https://bugs.winehq.org/show_bug.cgi?id=52396
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #6 from Louis Lenders xerox.xerox2000x@gmail.com --- *** Bug 52151 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #7 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 72047 --> https://bugs.winehq.org/attachment.cgi?id=72047 patch against current git
I found this actually works (is fixed) in Glorious Eggroll`s wine-ge-custom (https://github.com/GloriousEggroll/wine-ge-custom)
Suspecting the problem to be in ntdll/signal_x86_64.c I just copied over that file from wine-ge-custom to current git, and that fixes the bug. Now 64-bit dotnet core 6 works as expected and also 64 bit Powershell Core (>7,2) doesn't crash anymore.
I don`t know whose patch it is, or if it is a combination of patches but my guess is, it`s from Paul Gofman, so maybe he could shed a light on this bug?
https://bugs.winehq.org/show_bug.cgi?id=52396
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Stack overflows when |Stack overflows when |running 64-bit .net6 |running any 64-bit .Net 6 |program |(.Net Core) program Component|-unknown |ntdll
https://bugs.winehq.org/show_bug.cgi?id=52396
nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=52396
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #8 from Paul Gofman pgofman@codeweavers.com --- This is my patch from official Proton, where it got to GE custom probably and where it has proper subject and authorship.
The background of the issue is that .Net 6 has its own replacement for RtlRestoreContext. Wine uses a workaround for own exception handlers on x64: using TIB handlers just like on i386 and pops them in RtlRestoreContext. When the handkers are not popped they are erroneously used later with unrelated stack contents. My patch adds the functionally correct handling of that for exception processing part, although it is not a complete solution as there are more Wine handlers which are not fixed by this patch. Upstream solution is waiting fir proper .seh exception handling support by compiler.
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #9 from Paul Gofman pgofman@codeweavers.com --- Here is the right patch: https://github.com/ValveSoftware/wine/commit/157c6cbeb57355384b7ac53558cb961...
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #10 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Paul Gofman from comment #9)
Here is the right patch: https://github.com/ValveSoftware/wine/commit/ 157c6cbeb57355384b7ac53558cb96101d3ede10
Hi Paul, thanks for the clarification.
Upstream solution is waiting fir proper .seh exception handling support by compiler.
Meanwhile could patch maybe added to Staging, so that also non-gamers could get affected applications running?
Regards
https://bugs.winehq.org/show_bug.cgi?id=52396
m0rvj johnpgoodman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johnpgoodman@gmail.com
--- Comment #11 from m0rvj johnpgoodman@gmail.com --- Just wondering if this is submitted to staging? I've tested the patch and found it helpful.
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #12 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to m0rvj from comment #11)
Just wondering if this is submitted to staging? I've tested the patch and found it helpful.
+1
@Alistair/@Zebediah: Could you consider to include Paul`s patch in Staging please?
Thanks in advance
https://bugs.winehq.org/show_bug.cgi?id=52396
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alt.ti-a8gprwn@yopmail.com
--- Comment #13 from Nikolay Sivov bunglehead@gmail.com --- *** Bug 53178 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #14 from m0rvj johnpgoodman@gmail.com --- Using .NET 6 I'm getting a lot of out of Memory errors... Could this be a deficiency in the patch? Or something unrelated?
https://bugs.winehq.org/show_bug.cgi?id=52396
CryoMyst@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |CryoMyst@hotmail.com
--- Comment #15 from CryoMyst@hotmail.com --- Also becoming a problem, is a fix going to be merged to staging?
https://bugs.winehq.org/show_bug.cgi?id=52396
Frank franksauer@cox.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |franksauer@cox.net
https://bugs.winehq.org/show_bug.cgi?id=52396
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/ntdll-wine-frame | |s CC| |leslie_alistair@hotmail.com Status|NEW |STAGED
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #16 from m0rvj johnpgoodman@gmail.com --- Seems to work well, can it go into devel?
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #17 from m0rvj johnpgoodman@gmail.com --- Any way this can be put into 8 stable? I have loads of people using it...
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #18 from Frank franksauer@cox.net --- I'd like to second the question of whether this can be merged to Stable. We do have a number of users relying on it and we would be able to really test program functionality on Stable with a broader user base.
https://bugs.winehq.org/show_bug.cgi?id=52396
Julian Xhokaxhiu xhokaxhiujulian@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xhokaxhiujulian@gmail.com
--- Comment #19 from Julian Xhokaxhiu xhokaxhiujulian@gmail.com --- Is it possible to provide an update from the Wine core team on the status of this bug? Will they merge it? Will they tackle it differently? Will it otherwise be possible to start having a Wine Staging flatpak that we can base other apps to?
Thank you in advance
https://bugs.winehq.org/show_bug.cgi?id=52396
magino maginosk@azet.sk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maginosk@azet.sk
--- Comment #20 from magino maginosk@azet.sk --- My experiences with ASP .NET Core app .NET 6+ and wine:
I'm using wine in docker - scottyhardy/docker-wine
ASP .NET Core .NET6+ x64 app with wine 7.0.1 => do not even starts, stack overflow exception is thrown.
ASP .NET Core .NET6+ x86 with wine 7.0.1 or 8.0 works fine. But I use wine just because I want to run .NET core app which calls c++ x64 library trough interop. C++ x64 library is dependent on windows and I need to run this app in docker with linux engine => so I use this wine image for that scottyhardy/docker-wine.
ASP .NET Core .NET6+ x64 app with wine 8.0 => starts, my api calls work fine until some exception is thrown. When exceptions are thrown again stack overflow wine error occurs.
Right now I use .NET 5 x64 with wine 8.0.
https://bugs.winehq.org/show_bug.cgi?id=52396
tinozzo123@tutanota.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tinozzo123@tutanota.com
--- Comment #21 from tinozzo123@tutanota.com --- *** Bug 53379 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=52396
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #22 from Fabian Maurer dark.shadow4@web.de --- *** Bug 55044 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #23 from m0rvj johnpgoodman@gmail.com --- (In reply to Julian Xhokaxhiu from comment #19)
Is it possible to provide an update from the Wine core team on the status of this bug? Will they merge it? Will they tackle it differently? Will it otherwise be possible to start having a Wine Staging flatpak that we can base other apps to?
Thank you in advance
Indeed, we've been using the patch in staging for a long time with no issues, can it not be merged into devel?
In the meantime we are bundling an appImage from https://github.com/mmtrt/WINE_AppImage
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #24 from Fabian Maurer dark.shadow4@web.de --- AFAIK the problem is that Wine doesn't handle x64 exception correctly, and this should be fixed. I don't expect the patch to get merged.
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #25 from Paul Gofman pgofman@codeweavers.com --- Yes, it was discussed back then and the workarounds with manually coding .seh exception handlers are not accepted. This is waiting for proper compiler support.
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #26 from m0rvj johnpgoodman@gmail.com --- I hadn't understood that, so does that mean other crashes we are seeing could be connected to this?
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #27 from Paul Gofman pgofman@codeweavers.com --- (In reply to m0rvj from comment #26)
I hadn't understood that, so does that mean other crashes we are seeing could be connected to this?
It is obviously impossible to say whether some other unknown crashes are connected or not, but I think the majority of issues which may come from present Wine's try / catch workaround on x86_64 should be covered by the patch referenced in this bug plus this one: https://github.com/ValveSoftware/wine/commit/a706e43bcdf7d58a6c519742a3b9afc...
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #28 from Alexandre Julliard julliard@winehq.org --- (In reply to Paul Gofman from comment #25)
Yes, it was discussed back then and the workarounds with manually coding .seh exception handlers are not accepted. This is waiting for proper compiler support.
FWIW I don't think that using .seh manually is necessarily a blocker. But it would need to at least not make things worse for platforms that don't have .seh.
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #29 from Paul Gofman pgofman@codeweavers.com --- Thanks, I will look into updating the patches and sending them (starting from the simpler one with RtlUserThreadStart probably).
https://bugs.winehq.org/show_bug.cgi?id=52396
--- Comment #30 from m0rvj johnpgoodman@gmail.com --- (In reply to Paul Gofman from comment #27)
(In reply to m0rvj from comment #26)
I hadn't understood that, so does that mean other crashes we are seeing could be connected to this?
It is obviously impossible to say whether some other unknown crashes are connected or not, but I think the majority of issues which may come from present Wine's try / catch workaround on x86_64 should be covered by the patch referenced in this bug plus this one: https://github.com/ValveSoftware/wine/commit/ a706e43bcdf7d58a6c519742a3b9afcf233289b9
Do you think these might be duplicates?: 1) https://github.com/ferion11/LogosLinuxInstaller/issues/105 2) https://bugs.winehq.org/show_bug.cgi?id=54870 3) https://bugs.winehq.org/attachment.cgi?id=75246
https://bugs.winehq.org/show_bug.cgi?id=52396
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |48aa9031ab5e600413e7ca7905b | |ba40dbed0b2f6
--- Comment #31 from Paul Gofman pgofman@codeweavers.com --- This should now be fixed after 48aa9031ab5e600413e7ca7905bba40dbed0b2f6.
https://bugs.winehq.org/show_bug.cgi?id=52396
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #32 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.19.
-
WineHQ Bugzilla