-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
createdump crash report can have multiple threads indicated as crashed #60932
Comments
Tagging subscribers to this area: @mangod9 Issue DetailsDescriptionIt appears like a faulted task with an unobserved exception can cause the threadpool thread to be marked "crashed" in future crash reports. Or said differently, if the process crashes while a faulted task has not yet had it's exception observed, both the actual crashing thread and the threadpool thread that ran the faulted task, will be marked "crashed" in the crash report json. Reproduction StepsRun a task on a background thread that throws, but never observe the exception. Then crash the process on the main thread. Expected behaviorOnly the crashing thread is marked crashed. Actual behaviorMultiple threads are marked as the crashing thread in the crash report. Regression?No response Known WorkaroundsNo response ConfigurationNo response Other informationNo response
|
cc @mikem8361 |
Tagging subscribers to this area: @tommcdon Issue DetailsDescriptionIt appears like a faulted task with an unobserved exception can cause the threadpool thread to be marked "crashed" in future crash reports. Or said differently, if the process crashes while a faulted task has not yet had it's exception observed, both the actual crashing thread and the threadpool thread that ran the faulted task, will be marked "crashed" in the crash report json. Reproduction StepsRun a task on a background thread that throws, but never observe the exception. Then crash the process on the main thread. Expected behaviorOnly the crashing thread is marked crashed. Actual behaviorMultiple threads are marked as the crashing thread in the crash report.
|
Fixes issue: dotnet#60932
Fix dump generation issues for VS4Mac Fixes issue: #60932 Fix how the load bias is calculate for shared modules Add new generate core dump IPC command that allows the generate crash report flag to be passed through to createdump for VS4Mac. Issue: #60775 VS4Mac needs to distinguish between WriteDump/no signal and unknown signal ExceptionType Change unknown signal exception type to 0
The VS4Mac team found two issues preventing them from successfully diagnosing VS4Mac failures on .NET: 1) Multiple "crashed" threads in the crash report json (dotnet#60932). 2) No flag or way to generate the crash report for hangs via the diagnostic server IPC commands (dotnet#60775). Add new generate core dump IPC command that allows the generate crash report flag to be passed through to createdump for VS4Mac. VS4Mac needs to distinguish between WriteDump/no signal and unknown signal ExceptionType. Change unknown signal exception type to 0. Issue: dotnet#60775 Fix how the load bias is calculate for shared modules Local testing with the SOS tests. VS4Mac team testing and verification. Low risk because it only affects createdump, dump IPC command and the runtime dump generation path.
The VS4Mac team found two issues preventing them from successfully diagnosing VS4Mac failures on .NET: 1) Multiple "crashed" threads in the crash report json (#60932). 2) No flag or way to generate the crash report for hangs via the diagnostic server IPC commands (#60775). Add new generate core dump IPC command that allows the generate crash report flag to be passed through to createdump for VS4Mac. VS4Mac needs to distinguish between WriteDump/no signal and unknown signal ExceptionType. Change unknown signal exception type to 0. Issue: #60775 Fix how the load bias is calculate for shared modules Local testing with the SOS tests. VS4Mac team testing and verification. Low risk because it only affects createdump, dump IPC command and the runtime dump generation path.
Description
It appears like a faulted task with an unobserved exception can cause the threadpool thread to be marked "crashed" in future crash reports. Or said differently, if the process crashes while a faulted task has not yet had it's exception observed, both the actual crashing thread and the threadpool thread that ran the faulted task, will be marked "crashed" in the crash report json.
Reproduction Steps
Run a task on a background thread that throws, but never observe the exception. Then crash the process on the main thread.
Expected behavior
Only the crashing thread is marked crashed.
Actual behavior
Multiple threads are marked as the crashing thread in the crash report.
The text was updated successfully, but these errors were encountered: