-
Notifications
You must be signed in to change notification settings - Fork 3.8k
[2020-02] Start a dedicated thread for MERP crash reporting #21126
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
Merged
lambdageek
merged 21 commits into
mono:2020-02
from
lambdageek:merp-dedicated-thread-2020-02
Jun 24, 2021
Merged
[2020-02] Start a dedicated thread for MERP crash reporting #21126
lambdageek
merged 21 commits into
mono:2020-02
from
lambdageek:merp-dedicated-thread-2020-02
Jun 24, 2021
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At process startup, start a separate thread that is attached to the runtime and can collect crash reports. Crashing threads will wake it and wait for it to collect the crash reports
We need to coordinate the originator and the leader in a few places. The leader needs to pause to after collecting the thread ids before suspending the non-originator threads, and again while the originator is dumping its own stack. The originator needs to wait for the leader to collect the thread IDs and to tell it its assigned slot. Then it tells the leader to suspend the others, dumps its own memory, then tell the leader to dump the whole crash report and wait for it to reply when it's done.
either because the crash leader crashed, or because the process got a SIGTERM and it arrived on the crash leader thread
It's straightline code with two early exits. State machine is overkill
CoffeeFlux
approved these changes
Jun 23, 2021
Member
Author
|
@monojenkins build failed |
lambdageek
added a commit
to lambdageek/mono
that referenced
this pull request
Oct 6, 2021
…ono#21126)" This reverts commit 6303563.
akoeplinger
pushed a commit
that referenced
this pull request
Oct 7, 2021
rolfbjarne
added a commit
to rolfbjarne/macios
that referenced
this pull request
Dec 15, 2021
New commits in mono/mono: * mono/mono@b8d7525156a [2020-02] [cominterop] Add coop handle enter/return on native CCW methods * mono/mono@2ca650f1f62 [2020-02] Adds full path to libcairo for correct assembly directory resolution in monterey * mono/mono@e750cb3ee50 [aot] Prepend the assembly name to the names of gsharedvt wrappers to avoid duplicate symbol errors during static linking. * mono/mono@b32801a63cf Remove NuGet.config * mono/mono@dfcef746405 Allow nfloat to be in the ObjCRuntime namespace, and make it work for Xamarin.MacCatalyst.dll as well. * mono/mono@5ce143a1a88 Revert "[2020-02] Start a dedicated thread for MERP crash reporting (mono/mono#21126)" Diff: https://github.com/mono/mono/compare/4150e65c9e3fb6a63afe6ac7f6ad9e90a7df971b..b8d7525156acaecf311ba468147caa74d8c190f6
rolfbjarne
added a commit
to dotnet/macios
that referenced
this pull request
Dec 15, 2021
New commits in mono/mono: * mono/mono@b8d7525156a [2020-02] [cominterop] Add coop handle enter/return on native CCW methods * mono/mono@2ca650f1f62 [2020-02] Adds full path to libcairo for correct assembly directory resolution in monterey * mono/mono@e750cb3ee50 [aot] Prepend the assembly name to the names of gsharedvt wrappers to avoid duplicate symbol errors during static linking. * mono/mono@b32801a63cf Remove NuGet.config * mono/mono@dfcef746405 Allow nfloat to be in the ObjCRuntime namespace, and make it work for Xamarin.MacCatalyst.dll as well. * mono/mono@5ce143a1a88 Revert "[2020-02] Start a dedicated thread for MERP crash reporting (mono/mono#21126)" Diff: https://github.com/mono/mono/compare/4150e65c9e3fb6a63afe6ac7f6ad9e90a7df971b..b8d7525156acaecf311ba468147caa74d8c190f6
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #21096 to
2020-02Related to #21009.
There are two scenarios:
kill -TERM <pid>), the process can receive the signal on any thread,The crash reporter assumes that the crashing thread is either attached to the runtime, or at least
mono_thread_info_currentor the JIT TLS data are set for the thread. If the thread is truly foreign and it never interacted with Mono, and it crashes, both of those assumptions are false, but Mono's crash reporter signal handlers still run.The solution from this PR is: if crash reporting is enabled, start a dedicated thread at process startup that is a "crash report leader" - when a crash happens, the crashing thread (the crash originator) wakes the leader, and the leader collects the crash report. The crash originator does not do any work that requires being attached to the runtime or to the JIT such as iterating over thread IDs or stack walking.