Infinite recursion during resource lookup within System.Private.CoreLib #32510
Comments
Dotnet-GitSync-Bot
added
the
untriaged
|
From Slack: This happens when you're missing |
CoffeeFlux
added
area-Build-mono
and removed
area-GC-mono
untriaged
|
/cc @steveisok |
This doesn't seem to solve this problem. |
|
I can reproduce. And what's weird is that It's important to point out that this all works normal when you don't run under Here's the last bit of the mono trace before it bombs: /cc @lambdageek |
|
It could be a few issues mixed together. DOTNET_SYSTEM_GLOBALIZATION_INVARIANT requires some hook to be ready very early. We might be not accomodating for that and it's worth checking if it works at all. There is also some ugly code in https://github.com/dotnet/runtime/blob/master/src/libraries/System.Private.CoreLib/src/System/SR.cs#L95 which might be CoreCLR specific. /cc @lambdageek |
|
I did another pass with and without Without: |
|
Could you paste the log with the setting of the env variable? |
|
The loader behavior looks fine to me from the logs. In the non- |
|
That's in the gist above. Do you mean w/o? |
|
Yeah without, sorry. |
|
Without |
|
This is reproducible with just a Hello World. Additionally, on OSX I can get a managed stack trace. Crash info below: |
|
Could this be a similar to: #1716? In the case of the 1716, it is believed that the failure is due to a runtime vs corelib mismatch. |
|
The exception the GetResourceString issue was covering up: |
|
cc: @EgorBo |
|
With the latest stack trace, I'd more confidently say this is a duplicate of #1716 (#32510 (comment)). |
|
Yep, looks like the same type of failure, though I would expect this is a Mono build issue rather than a true duplicate? |
Yes, probably. The failure would indicate that the build is pulling a version of S.P.Corelib built for ARM/ARM64 or for 32-bit Unix: https://github.com/dotnet/runtime/blob/master/src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems#L1740-L1756 While the runtime believes that the ISA should be |
|
Seems the issue here is purely that corlib uses intrinsics on some platforms that we didn't have implemented, not a platform inconsistency. Egor's PR adds the missing ones, which should fix this particular issue, but we should probably handle that case better and surface the actual exception if possible. |
For now we only implement intrinsics used by corlib internally to optimize code. Fixes dotnet/runtime#32510 crash. `ConvertScalarToVector128UInt32/64` is expanded into LLVM's `insertelement` `ConvertToUInt32/64` is expanded into LLVM's `extractelement`
For now we only implement intrinsics used by corlib internally to optimize code. Fixes dotnet/runtime#32510 crash. `ConvertScalarToVector128UInt32/64` is expanded into LLVM's `insertelement` `ConvertToUInt32/64` is expanded into LLVM's `extractelement` Co-authored-by: Egor Bogatov <egorbo@gmail.com>
ghost
locked as resolved and limited conversation to collaborators
Steps to Reproduce on linux
./build.sh -c Release /p:MonoEnableLLVM=trueCurrent Behavior
CLR: Managed code called FailFast, saying "Infinite recursion during resource lookup within System.Private.CoreLib. This may be a bug in System.Private.CoreLib, or potentially in certain extensibility points such as assembly resolve events or CultureInfo names. Resource name: Arg_PlatformNotSupported"
Expected Behavior
No crash
On which platforms did you notice this
[x] macOS
[x] Linux
[ ] Windows
Version Used:
dotnet/runtime 13c1e65
Stacktrace
The text was updated successfully, but these errors were encountered: