Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[merp] Introduce a new 'dump mode' that allows different signal behavior when dumping #17537

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.

Sign up for GitHub

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

Jump to bottom
Merged
lambdageek merged 9 commits into from
Oct 26, 2019
Merged

[merp] Introduce a new 'dump mode' that allows different signal behavior when dumping #17537

lambdageek merged 9 commits into from
Oct 26, 2019

Conversation

@alexischr
Copy link
Contributor

@alexischr alexischr commented Oct 24, 2019 •
edited
Loading

[merp] Introduce a new 'dump mode' that allows different signal behavior when dumping

The primary reason for this is gaining the ability to interpret SIGTERM properly as a crashing signal when outside of 'dump mode', and as a utility signal during the 'thread summarizer' dumping process.

Addresses #17419

@alexischr alexischr force-pushed the merp-dump-mode-sigterm-fix branch 3 times, most recently from 22cf584 to 1452e2f Compare October 24, 2019 10:53
@alexischr alexischr changed the title Merp dump mode sigterm fix merp] Introduce a new 'dump mode' that allows different signal behavior when dumping Oct 24, 2019
@alexischr alexischr changed the title merp] Introduce a new 'dump mode' that allows different signal behavior when dumping [merp] Introduce a new 'dump mode' that allows different signal behavior when dumping Oct 24, 2019
lambdageek
lambdageek reviewed Oct 24, 2019
View reviewed changes
@alexischr
Copy link
Contributor Author

alexischr commented Oct 24, 2019 •
edited
Loading

@lambdageek There is one failing test (DumpICallTotalConcurrent) which is totally expected. DumpStateTotal should fail if attempted concurrently, since the mechanism it uses can't be used that way. I think that the data coming out of such concurrent calls is probably not sound, do you agree?

@alexischr
Copy link
Contributor Author

alexischr commented Oct 24, 2019

Okay I see from your comment you expect a "sleep and retry" instead of a failure for DumpStateTotal

@lambdageek
Copy link
Member

lambdageek commented Oct 24, 2019

@alexischr There's some code in mono_threads_summarize that is meant to allow only a single summarizer request to go through. So for DumpStateTotal we can actually let it run all the way down to the point where it calls mono_threads_summarize, and that inner queueing will take care to let only a single thread through.

mono/mono/metadata/threads.c

Lines 6637 to 6658 in 638e2c6

// The staggered values are due to the need to use inc_i64 for the first value
static gint64 next_pending_request_id = 0;
static gint64 request_available_to_run = 1;
gint64 this_request_id = mono_atomic_inc_i64 ((volatile gint64 *) &next_pending_request_id);
// This is a global queue of summary requests.
// It's not safe to signal a thread while they're in the
// middle of a dump. Dladdr is not reentrant. It's the one lock
// we rely on being able to take.
//
// We don't use it in almost any other place in managed code, so
// our problem is in the stack dumping code racing with the signalling code.
//
// A dump is wait-free to the degree that it's not going to loop indefinitely.
// If we're running from a crash handler block, we're not in any position to
// wait for an in-flight dump to finish. If we crashed while dumping, we cannot dump.
// We should simply return so we can die cleanly.
//
// signal_handler_controller should be set only from a handler that expects itself to be the only
// entry point, where the runtime already being dumping means we should just give up
gboolean success = FALSE;

@alexischr alexischr force-pushed the merp-dump-mode-sigterm-fix branch 2 times, most recently from b847e5d to ffee39a Compare October 24, 2019 23:11
@lambdageek
Copy link
Member

lambdageek commented Oct 24, 2019

@monojenkins build pkg

@lambdageek
Copy link
Member

lambdageek commented Oct 24, 2019

@monojenkins backport to 2019-08

@alexischr alexischr marked this pull request as ready for review October 24, 2019 23:25
@monojenkins monojenkins mentioned this pull request Oct 24, 2019
Closed
lambdageek
lambdageek reviewed Oct 24, 2019
View reviewed changes
@alexischr alexischr force-pushed the merp-dump-mode-sigterm-fix branch 2 times, most recently from b5d932f to ad81229 Compare October 24, 2019 23:36
@alexischr
Copy link
Contributor Author

alexischr commented Oct 24, 2019

@monojenkins build pkg

@lambdageek
Copy link
Member

lambdageek commented Oct 24, 2019

There are a few more callers of mono_handle_native_crash that need to be fixed:
mono/mini/exceptions-amd64.c
mono/mini/exceptions-ppc.c

lambdageek
lambdageek previously approved these changes Oct 24, 2019
View reviewed changes
Copy link
Member

@lambdageek lambdageek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks conceptually ready.
some build failures to sort out on DISABLE_CRASH_REPORTING configurations.

@alexischr
[merp] Introduce a new 'dump mode' that allows different signal behav…
d2764d3 
…ior when dumping

The primary reason for this is gaining the ability to interpret SIGTERM properly as a crashing signal when outside of 'dump mode', and as a utility signal during the 'thread summarizer' dumping process.
@alexischr alexischr force-pushed the merp-dump-mode-sigterm-fix branch from ad81229 to d2764d3 Compare October 25, 2019 00:06
lambdageek
lambdageek reviewed Oct 25, 2019
View reviewed changes
lambdageek
lambdageek reviewed Oct 25, 2019
View reviewed changes
lambdageek
lambdageek reviewed Oct 25, 2019
View reviewed changes
@alexischr alexischr force-pushed the merp-dump-mode-sigterm-fix branch from 2d15a57 to e64ba3d Compare October 25, 2019 20:03
lambdageek
lambdageek reviewed Oct 25, 2019
View reviewed changes
@lambdageek
add braces
2c43dd9
@lambdageek
fix windows
1e9f19d
@lambdageek
Revert "fix windows"
a7331a6 
This reverts commit 1e9f19d.

Oops. pushed to the wrong branch
@alexischr
Copy link
Contributor Author

alexischr commented Oct 26, 2019

Let's try the auto-backport one more time:

@monojenkins backport to 2019-10
@monojenkins backport to 2019-08

@alexischr
Copy link
Contributor Author

alexischr commented Oct 26, 2019

@monojenkins build failed

This was referenced Oct 26, 2019
Merged
Merged
@mono mono deleted a comment from monojenkins Oct 26, 2019
@mono mono deleted a comment from monojenkins Oct 26, 2019
@alexischr
Copy link
Contributor Author

alexischr commented Oct 26, 2019

@monojenkins build failed

@lambdageek lambdageek merged commit db568c6 into mono:master Oct 26, 2019
lambdageek added a commit to lambdageek/mono that referenced this pull request Oct 28, 2019
@lambdageek
[2019-08][merp] Install sigterm handler in EnableMicrosoftTelemetry
0732123 
Partly revert mono#17296 backports.

Follow-up work for backports of mono#17537 backports.

Addresses mono#17419
@lambdageek lambdageek mentioned this pull request Oct 28, 2019
Merged
monojenkins pushed a commit to monojenkins/mono that referenced this pull request Oct 28, 2019
@lambdageek @monojenkins
[2019-08][merp] Install sigterm handler in EnableMicrosoftTelemetry
3d759f1 
Partly revert mono#17296 backports.

Follow-up work for backports of mono#17537 backports.

Addresses mono#17419
@monojenkins monojenkins mentioned this pull request Oct 28, 2019
Merged
alexischr pushed a commit that referenced this pull request Oct 28, 2019
@lambdageek @alexischr
[2019-08][merp] Install sigterm handler in EnableMicrosoftTelemetry
d234d34 
Partly revert #17296 backports.

Follow-up work for backports of #17537 backports.

Addresses #17419
alexischr pushed a commit that referenced this pull request Oct 28, 2019
@lambdageek @alexischr
[2019-08][merp] Install sigterm handler in EnableMicrosoftTelemetry
1de5d71 
Partly revert #17296 backports.

Follow-up work for backports of #17537 backports.

Addresses #17419
@lambdageek lambdageek mentioned this pull request Oct 29, 2019
Closed
@alexischr alexischr mentioned this pull request Dec 2, 2019
Closed
ManickaP pushed a commit to ManickaP/runtime that referenced this pull request Jan 20, 2020
@alexischr @lambdageek
[merp] Introduce a new 'dump mode' that allows different signal behav…
cc2f1e7 
…ior when dumping (mono/mono#17537)

* dump_native_stacktrace should always register the sigterm handler.

Cherry picked from the mono/mono#17310

* [merp] Introduce a new 'dump mode' that allows different signal behavior when dumping

The primary reason for this is gaining the ability to interpret SIGTERM properly as a crashing signal when outside of 'dump mode', and as a utility signal during the 'thread summarizer' dumping process.



Commit migrated from mono/mono@db568c6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@BrzVlad BrzVlad Awaiting requested review from BrzVlad

@lewurm lewurm Awaiting requested review from lewurm

@SamMonoRT SamMonoRT Awaiting requested review from SamMonoRT

@thaystg thaystg Awaiting requested review from thaystg

@vargaz vargaz Awaiting requested review from vargaz

@akoeplinger akoeplinger Awaiting requested review from akoeplinger

@kg kg Awaiting requested review from kg

@lateralusX lateralusX Awaiting requested review from lateralusX

1 more reviewer

@lambdageek lambdageek lambdageek approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

area-Runtime: Crash Reporting

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@alexischr @lambdageek @vargaz