Skip to content
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

Closed
kdubau opened this issue Oct 27, 2021 · 3 comments
Closed

createdump crash report can have multiple threads indicated as crashed #60932

kdubau opened this issue Oct 27, 2021 · 3 comments
Assignees
Milestone

Comments

@kdubau
Copy link
Member

kdubau commented Oct 27, 2021

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.

@dotnet-issue-labeler dotnet-issue-labeler bot added area-System.Threading untriaged New issue has not been triaged by the area owner labels Oct 27, 2021
@ghost
Copy link

ghost commented Oct 27, 2021

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details

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.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author: kdubau
Assignees: -
Labels:

area-System.Threading, untriaged

Milestone: -

@kdubau
Copy link
Member Author

kdubau commented Oct 27, 2021

cc @mikem8361

@mikem8361 mikem8361 added this to the 6.0.0 milestone Oct 27, 2021
@mikem8361 mikem8361 self-assigned this Oct 27, 2021
@mikem8361 mikem8361 added area-Diagnostics-coreclr and removed untriaged New issue has not been triaged by the area owner labels Oct 27, 2021
@ghost
Copy link

ghost commented Oct 27, 2021

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

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.

Author: kdubau
Assignees: mikem8361
Labels:

area-System.Threading, area-Diagnostics-coreclr

Milestone: 6.0.0

@kdubau kdubau changed the title createdump crash report can have multiple threads indicated as the crashed createdump crash report can have multiple threads indicated as crashed Oct 27, 2021
mikem8361 added a commit to mikem8361/runtime that referenced this issue Oct 27, 2021
mikem8361 added a commit that referenced this issue Nov 1, 2021
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
mikem8361 added a commit to mikem8361/runtime that referenced this issue Nov 1, 2021
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.
@mikem8361 mikem8361 modified the milestones: 6.0.0, 6.0.x Nov 5, 2021
Anipik pushed a commit that referenced this issue Nov 9, 2021
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.
@ghost ghost locked as resolved and limited conversation to collaborators Dec 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants