Mono GC crash in CI #58062
Assignees
Labels
Milestone
Comments
dotnet-issue-labeler
bot
added
the
untriaged
|
Tagging subscribers to this area: @BrzVlad Issue Detailscc @marek-safar @lambdageek @vargaz
|
This was referenced Aug 24, 2021
|
Grabbed one of the crash logs here: https://gist.github.com/lambdageek/cc4e2e34186e1b183c44d2c85bd00e96 in case they expire. |
|
Adding to milestone 7.0 - not a 100% reproable issue. @BrzVlad will do more investigation and we can consider a backport if necessary. |
|
When did this start happening? I can't think of anything offhand that has happened in the last week or two that would break allocation or GC. |
|
Possibly related (not as a cause, but as a workaround for a similar issue): #55598 |
|
A few observations about the causes of this issue :
|
This was referenced Sep 3, 2021
fanyang-mono
added
the
disabled-test
|
We'll see if anything can be done so llvm doesn't reconstruct obj refs. Otherwise we'll just disable sroa for 6.0 and investigate this issue later. |
|
I'm taking a look at workarounds now. I don't have a perf comparison. |
ghost
added
the
in-pr
imhameed
added a commit
to imhameed/runtime
that referenced
this issue
Sep 13, 2021
LLVM's SROA can decompose loads and stores of aggregate type into a sequence of aggregate-element-typed loads and stores. Before this change, Mono translates .NET-level value types into LLVM IR-level structs containing nothing but `i8` elements. When a value type field has reference type, and a value of this value type is copied using a `memcpy` intrinsic or an LLVM IR load followed by a store, LLVM will emit code that loads managed references in multiple byte-sized fragments before reconstructing the original pointer using a sequence of ALU ops. This causes sgen to fail to pin the referent. This change works around this by translating value types to LLVM IR structs with pointer-sized fields. Packed value types with non-standard alignment will be translated into LLVM IR structs containing alignment-sized fields. Note that this does not completely guarantee that the code we generate will respect sgen's requirements. No specific guarantees are provided about the translation of non-atomic LLVM IR loads and stores to machine code. And we'll need some alternative means (perhaps a special `gc_copy_unaligned` runtime call or similar) to copy packed or misaligned value types that contain managed references. For stronger LLVM IR-level guarantees, we'll want to make use of unordered atomic loads and stores and unordered atomic memcpy, but that work is out of scope for this change. Fixes dotnet#58062, but see the previous paragraph for caveats. See: - https://github.com/dotnet/llvm-project/blob/release/11.x/llvm/lib/Transforms/Scalar/SROA.cpp#L3371-L3388 - https://github.com/dotnet/llvm-project/blob/release/11.x/llvm/lib/Transforms/Scalar/SROA.cpp#L3327-L3340
imhameed
added a commit
that referenced
this issue
Sep 14, 2021
LLVM's SROA can decompose loads and stores of aggregate type into a sequence of aggregate-element-typed loads and stores. Before this change, Mono translated .NET-level value types into LLVM IR-level structs containing nothing but `i8` elements. When a value type field has reference type, and a value of this value type is copied using a `memcpy` intrinsic or an LLVM IR load followed by a store, LLVM will emit code that loads managed references in multiple byte-sized fragments before reconstructing the original pointer using a sequence of ALU ops. This causes sgen to fail to pin the referent. This change works around this by translating value types to LLVM IR structs with pointer-sized fields. Packed value types with non-standard alignment will be translated into LLVM IR structs containing alignment-sized fields. Note that this does not completely guarantee that the code we generate will respect sgen's requirements. No specific guarantees are provided about the translation of non-atomic LLVM IR loads and stores to machine code. And we'll need some alternative means (perhaps a special `gc_copy_unaligned` runtime call or similar) to copy packed or misaligned value types that contain managed references. For stronger LLVM IR-level guarantees, we'll want to make use of unordered atomic loads and stores and unordered atomic memcpy, but that work is out of scope for this change. Fixes #58062, but see the previous paragraph for caveats. See: - https://github.com/dotnet/llvm-project/blob/release/11.x/llvm/lib/Transforms/Scalar/SROA.cpp#L3371-L3388 - https://github.com/dotnet/llvm-project/blob/release/11.x/llvm/lib/Transforms/Scalar/SROA.cpp#L3327-L3340
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-58028-merge-0f18162b6a714630a6/JIT/1/console.71179669.log?sv=2019-07-07&se=2021-09-13T17%3A30%3A21Z&sr=c&sp=rl&sig=pNe9viQHA2TTqAOjNwkXgMqxXDAXFiw0aGviMCTofe4%3D
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-57928-merge-872ab46efd2b494988/JIT/1/console.607ded22.log?sv=2019-07-07&se=2021-09-12T13%3A23%3A40Z&sr=c&sp=rl&sig=t5BAIXU9yCaDHr2wqN84Z3t79kp2WWqPzP86f4JD2RA%3D
cc @marek-safar @lambdageek @vargaz
The native stack traces look like this:
The text was updated successfully, but these errors were encountered: