-
Notifications
You must be signed in to change notification settings - Fork 3.8k
[2019-06][merp] Don't install SIGTERM handler in EnableMicrosoftTelemetry #17296
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
[2019-06][merp] Don't install SIGTERM handler in EnableMicrosoftTelemetry #17296
Conversation
[merp] Put thread into async context before running summarizer Followup work for mono#17090 In order to get managed method info for unmanaged stacktraces, we call `mini_jit_info_table_find_ext` which calls `decode_exception_debug_info` which may allocate if it's not in async context. Do the switch in `mono_threads_summarize_execute` so that non-supervising threads all switch when they run the `sigterm_signal_handler`. `mono_threads_summarize` already does it for the supervisor thread. Fixes mono#17180 Backport of mono#17194. /cc @lambdageek
install_state_summarizer installs a SIGTERM handler. Unfortunately sigterm_signal_handler assumes that it will only be called when a crash is already in progress (it assumes it won't be the supervisor, and so it doesn't setup the memory for capturing a crash report among other things).
|
@monojenkins build pkg |
|
Verified that |
|
@monojenkins build failed |
Previously it was installed by EnableMicrosoftTelemetry, which is too early. Now we get here without a handler installed even when mono_merp_enabled returns true.
|
@monojenkins build pkg |
|
|
||
| mono_get_runtime_callbacks ()->install_state_summarizer (); | ||
| // Why does this install the sigterm handler so early? | ||
| // mono_get_runtime_callbacks ()->install_state_summarizer (); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid race conditions of installing the handler on multiple concurrent crashing threads?
To avoid the heap allocations in the crashing path (see the signal chaining)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest, perhaps, install the handler at the same time, but use a boolean to enable/disable it.
I'm just guessing.
| #endif | ||
|
|
||
| #ifndef DISABLE_STRUCTURED_CRASH | ||
| mini_register_sigterm_handler (); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably just be in the !leave block, otherwise we install a bit eagerly, even when !dump_for_merp or when DISABLE_STRUCTURED_CRASH is defined
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we want to install it if !dump_for_merp when DISABLE_STRUCTURED_CRASH is undefined? I thought that combination meant that we're going to dump a json file, but not upload to merp (in theory that's what CI should be doing)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I was misreading the !(dump_for_merp) block (the leave=true is still under a #ifdef)
|
@monojenkins build failed |
|
@monojenkins backport to 2019-08 |
|
@monojenkins backport to 2019-10 |
Partly revert mono#17296 backports. Follow-up work for backports of mono#17537 backports. Addresses mono#17419
Partly revert mono#17296 backports. Follow-up work for backports of mono#17537 backports. Addresses mono#17419
install_state_summarizer installs a SIGTERM handler. Unfortunately sigterm_signal_handler assumes that it will only be called when a crash is already in progress (it assumes it won't be the supervisor, and so it doesn't setup the memory for capturing a crash report among other things).
Addresses #17271