Thanks, I had a brief look and I think I see what is the issue with contexts here. Current version of the .Net code calls CopyContext with extended source context (which it initialized itself previously) to the context in exception record, using source context flags. The last part changed recently and that fails now (previously it was using flag from destination context and that should've worked). Our CopyContext() behaviour is correct here, we have a test for that: if destination context is not extended context and the source context is then CopyContext should fail. The problem is that RaiseException() provides extended context in exception record (at least on current Win10 where I checked that), while our RaiseException() currently doesn't.
On 8/19/22 12:55, Jakub Staroń (@js6pak) wrote:
On Fri Aug 19 17:31:41 2022 +0000, **** wrote:
Paul Gofman replied on the mailing list:
On 8/19/22 11:57, Jakub Staroń (@js6pak) wrote: >> It is interesting what's wrong with CopyContext. > It returns early here https://gitlab.winehq.org/wine/wine/-/blob/a34a403723661a3bf9c958c2431d58cce6c392bf/dlls/ntdll/exception.c#L1001 and causes coreclr to failfast. >> Is there any app which reproduces the issue? > I'd assume all x86 .NET 6.0 apps that use threading in anyway. > I wasn't able to get a very minimal repro so I just copied over code that was causing issues for me here: https://github.com/js6pak/CoreclrWineCrash Thanks. Sorry, I don't have dot net core building toolchains in hands, is it possible to download a binary version of reproducer from somewhere? I guess it is most interesting to fix CopyContext at the first place, even if that is not used on the main path in .Net core. _______________________________________________ wine-gitlab mailing list -- wine-gitlab@winehq.org To unsubscribe send an email to wine-gitlab-leave@winehq.orghttps://github.com/js6pak/CoreclrWineCrash/actions/runs/2891163269