-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
baseservices/exceptions/stackoverflow/stackoverflowtester/stackoverflowtester fails on Linux #46175
Comments
PTAL @echesakovMSFT I believe you were working with this test. |
No, @janvorli created this test |
I had no idea the test was disabled. @sandreenko where have you seen it failing with timeout? |
@janvorli it was in the same job, here the log https://dev.azure.com/dnceng/public/_build/results?buildId=923829&view=ms.vss-test-web.build-test-results-tab&runId=29324470&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab&resultId=102790 Note: the test is disabled again, I have disabled it in #46162 |
After I've fixed the lookup for the Main in the stack trace, the ARM64 legs are failing due to the fact that we don't have the probing helper change in yet. So for large frames, the failure point is too far from the SP, the failure is not recognized as stack overflow and the sigsegv alternate stack is not large enough to execute the full stack overflow reporting. The alternate stack is about two pages large while the stack overflow needs about 8 pages. We need to wait for the stack probing helper change to reenable the tests. |
is the stack probing helper change noted above merged, or is it still pending? |
The change was postponed to 7.0.0 - we need to fix #47810 first. Otherwise, enabling the stack probing helper introduces regressions. |
Ok thanks for the update. Moving this to 7 as well. |
Another set of tests have started to fail on
Should we disable all these tests until #47810 and this issues are resolved? |
@am11 I am not sure I understand connection between the failing profiler test and the issue with stack probing. Can you please elaborate? |
@echesakovMSFT, ah ok. The error from libunwind is "apply_reg_state: ip and cfa unchanged;", so I thought this issue is tracking that from the logs in the top post. Is that error unrelated and do we need to track it? |
@am11 Yes, it looks unrelated. |
@JulieLeeMSFT, Egor had pointed to this #47810 which needs to be merged before rechecking whether this test would pass. Is it planned for 7 (its currently marked as future)? |
moving this to 8. |
Looks like #47810 is still not merged. @JulieLeeMSFT @BruceForstall assume this is not planned for 8? |
@mangod9 Note that this test is disabled for all Linux, as well as for win-x86 (#84911). Issue #47810 is an optimization for arm64 only. The arm64 stack probing issue is #13519. There is no current plan to implement it. (cc @kunalspathak) But, as mentioned, that should only affect arm64. All the other test failures of this test (non-arm64 Linux and win-x86) could be independently investigated. |
@janvorli, would your recent exceptions work handle this case? If so we can move to 9 |
Looks like the disabled test was enabled as part of JanV's fix. Closing now. |
oh sorry, missed that the PR was closed before merging. Assuming we can enable again in 9 |
When multiple threads crash with hardware unhandled exceptions at the same time, the fact that we were uninstalling async signal handlers at process exit caused crashes when some thread reached the signal handler after .NET handler was removed. This change fixes it by not restoring the signal handlers during process exit. It actually stops restoring any signal handlers except for SIGABRT that has to be restored to actually enable the process exit with abort(). Close dotnet#46175
It was disabled so we have not seen it, the log is:
note that on some archs it fails with a timeout.
AzDo example.
The text was updated successfully, but these errors were encountered: