Test failure: Regressions/coreclr/GitHub_45929/test45929/test45929.cmd #98914
Labels
arch-arm64
arch-x64
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
blocking-clean-ci-optional
Blocking optional rolling runs
GCStress
JitStress
CLR JIT issues involving JIT internal stress modes
os-linux
Linux OS (any supported distro)
os-mac-os-x
macOS aka OSX
Comments
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsFailed in: runtime-coreclr gcstress-extra 20240224.1 Failed tests: Error message: Stack trace:
**Failed in:** [runtime-coreclr gcstress-extra 20240224.1](https://dev.azure.com/dnceng-public/public/_build/results?buildId=578457&view=ms.vss-test-web.build-test-results-tab&runId=13881248&resultId=112656&paneView=debug) Failed tests: Error message:*
|
janvorli
added a commit
to janvorli/runtime
that referenced
this issue
Feb 28, 2024
With the old EH, the unwound stack range limits are using SP for each frame on x64 and a caller SP on arm64, arm, riscv64 and longsoon. The ExceptionTracker::IsInStackRegionUnwoundBySpecifiedException takes that into consideration when detecting whether a frame with a specific SP was already unwound or not. With the new EH though, the range is always based on the actual SP of the frame, so the check was being done incorrectly on non-x64 architectures. That lead to a crash in a test that has dynamic method code on stack and its frame was unwound. The bug has caused that method to not to be reported to GC, so the dynamic method was destroyed by GC. And later on, another GC stack walk has crashed while trying to get info on the method. This change fixes it by making the check with new EH enabled the same for all architectures, the same as it was for x64 in the old EH. Close dotnet#98914
github-actions bot
pushed a commit
that referenced
this issue
Feb 28, 2024
With the old EH, the unwound stack range limits are using SP for each frame on x64 and a caller SP on arm64, arm, riscv64 and longsoon. The ExceptionTracker::IsInStackRegionUnwoundBySpecifiedException takes that into consideration when detecting whether a frame with a specific SP was already unwound or not. With the new EH though, the range is always based on the actual SP of the frame, so the check was being done incorrectly on non-x64 architectures. That lead to a crash in a test that has dynamic method code on stack and its frame was unwound. The bug has caused that method to not to be reported to GC, so the dynamic method was destroyed by GC. And later on, another GC stack walk has crashed while trying to get info on the method. This change fixes it by making the check with new EH enabled the same for all architectures, the same as it was for x64 in the old EH. Close #98914
janvorli
added a commit
that referenced
this issue
Feb 28, 2024
With the old EH, the unwound stack range limits are using SP for each frame on x64 and a caller SP on arm64, arm, riscv64 and longsoon. The ExceptionTracker::IsInStackRegionUnwoundBySpecifiedException takes that into consideration when detecting whether a frame with a specific SP was already unwound or not. With the new EH though, the range is always based on the actual SP of the frame, so the check was being done incorrectly on non-x64 architectures. That lead to a crash in a test that has dynamic method code on stack and its frame was unwound. The bug has caused that method to not to be reported to GC, so the dynamic method was destroyed by GC. And later on, another GC stack walk has crashed while trying to get info on the method. This change fixes it by making the check with new EH enabled the same for all architectures, the same as it was for x64 in the old EH. Close #98914
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Failed in: runtime-coreclr gcstress-extra 20240224.1
Failed tests:
Error message:
Stack trace:
The text was updated successfully, but these errors were encountered: