There is an interesting runtime behavior to report from testing on linux-musl-loongarch64 under QEMU emulation. While running the SmokeTests/DynamicGenerics suite, the test execution itself finishes and prints PASSED, but the binary immediately encounters a fatal crash during the test teardown phase inside RunTests. The application terminates with a raw Access Violation right as it hits the exception context mapping code inside System.Runtime.EH.GetClasslibException.
The full error log and stack trace from the run can be found here: https://github.com/am11/CrossRepoCITesting/actions/runs/29597960951/job/87942871820
>>> Running: /runtime/artifacts/tests/coreclr/linux.loongarch64.Checked/nativeaot/SmokeTests/DynamicGenerics/DynamicGenerics/native/DynamicGenerics
--------------------------------
Running Test: My.TestActivatorCreateInstance
Calling List<My>.ctor
System.Collections.Generic.List`1[My]
Adding item to List<My>
Calling List<My>.get_Count
Calling GC.Collect
Calling List<Foo>.ctor
System.Collections.Generic.List`1[Foo]
Adding item to List<Foo>
Calling List<My>.get_Count
Calling Dictionary<My,My>.ctor
System.Collections.Generic.Dictionary`2[My,My]
Adding item to Dictionary<My,My>
Calling Dictionary<My,My>.get_Count
Calling GC.Collect
Calling My.ctor
Calling My.TestMethod1() instance method
---- Test PASSED ---------------
Process terminated. Access Violation: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. The application will be terminated since this platform does not support throwing an AccessViolationException.
at System.RuntimeExceptionHelpers.FailFast(String, Exception, String, RhFailFastReason, IntPtr, IntPtr)
at System.RuntimeExceptionHelpers.GetRuntimeException(ExceptionIDs)
at System.Runtime.EH.GetClasslibException(ExceptionIDs, IntPtr)
at CoreFXTestLibrary.Internal.Runner.RunTests(TestInfo[], String[])
at EntryPointMain.Main(String[] args)
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted (core dumped)
/runtime/artifacts/tests/coreclr/linux.loongarch64.Checked/nativeaot/SmokeTests/DynamicGenerics/DynamicGenerics/native/DynamicGenerics failed with exit code 134
The most interesting clue is a distinct environment delta: the test passes 100% cleanly on Ubuntu (glibc) under QEMU, but reproducibly fails this single test on Alpine (musl) under the exact same emulation context. Because this behavior is exclusive to the musl target, it heavily implies a subtle difference in how the LoongArch64 RyuJIT backend handles stack alignment, exception registers, or TLS memory layouts during exception unwinding. I am sharing this data point with the arch-loongarch64 maintainers in case anyone wants to check the musl ABI layout handling when they have some time. Feel free to close if you think this is purely a QEMU translation artifact.
There is an interesting runtime behavior to report from testing on
linux-musl-loongarch64under QEMU emulation. While running theSmokeTests/DynamicGenericssuite, the test execution itself finishes and printsPASSED, but the binary immediately encounters a fatal crash during the test teardown phase insideRunTests. The application terminates with a raw Access Violation right as it hits the exception context mapping code insideSystem.Runtime.EH.GetClasslibException.The full error log and stack trace from the run can be found here: https://github.com/am11/CrossRepoCITesting/actions/runs/29597960951/job/87942871820
The most interesting clue is a distinct environment delta: the test passes 100% cleanly on Ubuntu (glibc) under QEMU, but reproducibly fails this single test on Alpine (musl) under the exact same emulation context. Because this behavior is exclusive to the musl target, it heavily implies a subtle difference in how the LoongArch64 RyuJIT backend handles stack alignment, exception registers, or TLS memory layouts during exception unwinding. I am sharing this data point with the
arch-loongarch64maintainers in case anyone wants to check the musl ABI layout handling when they have some time. Feel free to close if you think this is purely a QEMU translation artifact.