Open kg opened 6 days ago
cc @janvorli, this one looks like the foreign thread is not able to set the resolver on executing assembly https://github.com/dotnet/runtime/blob/d450d9c9ee4dd5a98812981dac06d2f92bdb8213/src/tests/baseservices/exceptions/unhandled/unhandled.cs#L27 (note that PR https://github.com/dotnet/runtime/pull/109204 will disable this test)
@kg is this is wasm specific or am I just mislead by the folder name in the log above?
The problem is that the tester expects to get
Unhandled exception. System.DllNotFoundException:
But it gets
Unhandled exception. System.EntryPointNotFoundException
If the issue is WASM only and it is expected that WASM would generate a different exception, then the src/tests/baseservices/exceptions/unhandled/unhandledTester.cs should be modified to check for a different exception on WASM.
I was not able to repro this on Linux x64.
This is regular CoreCLR. The tests only fails when compiled as R2R.
I think the problem is that the test is not properly compensating for variance in behavior that is allowed due to optimizations. From https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.suppressgctransitionattribute :
Applying this attribute can cause the P/Invoke export to be bound earlier as a side-effect of the calling method being JIT compiled. EntryPointNotFoundException or other exceptions might be thrown earlier than when the attribute is not applied.
It can fixed by moving code around and applying NoInline attributes to ensure that the behavior is not affected by optimizations.
I was actually trying to repro it on Linux x64 release build with R2R enabled and it didn't repro. So I wonder which DOTNET_xxx variables need to be set to get it repro.
This is my repro script, though it doesn't match CI for some reason:
rm -rf ./artifacts
rm -rf ./artifacts/tests
rm -rf ./.dotnet
./build.sh Clr+Tools+Libs -c Release -rc $1 --os linux
./src/tests/build.sh $1 -priority1 -crossgen2 -p:LibrariesConfiguration=Release
PATH=/home/kate/Projects/dotnet-runtime-wasm/.dotnet/:$PATH RunCrossGen2=1 CompositeBuildMode=1 src/tests/run.sh $1
With 'Checked' passed as $1 since a lot of the CI lanes are Checked. For me this repros around half of the CI failures.
Thank you @kg, the CompositeBuildMode=1
is what triggers the issue to happen.
I should have been more precise, sorry for wasting your time. I think the CI lanes are also composite.
No worries