On Wed, 13 Apr 2022 15:55:52 GMT, Johannes Bechberger <d...@openjdk.java.net> wrote:
>> Move the AsyncGetCallTrace method implementation into a separate method and >> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection` >> like it is done in >> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd29aee41ba2b1b0b0c67bb67eca22dd/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp#L165). >> This prevents AsyncGetCallTrace from crashing on segmentation faults (but >> not on `guarantee`s). >> >> If a crash is observed, then the `num_frames` field of the trace is set to >> `ticks_unknown_state` (-7) to signal a state that cannot be properly >> handled. `ticks_unknown_state` is currently also used for signaling unknown >> thread states but this should not be a problem, as the semantic is the same. >> If `num_frames` already has an error code then this error code is not >> changed. This helps to distinguish between errors in walking threads in Java >> and non-Java mode, as `num_frames` is set there before the walking to the >> appropriate error code. >> >> _Thanks for @tstuefe for suggesting this._ > > Johannes Bechberger has updated the pull request incrementally with one > additional commit since the last revision: > > Remove JFR assert from ThreadCrashProtection > > Remove the Thread::is_JfrSampler_thread() method too, > as it has only be used by the removed asserts At https://github.com/openjdk/jdk/blob/77a21cb5658961b20011b7125a1ed896622faa4d/src/hotspot/share/prims/forte.cpp#L461, you have a NoHandleMark which wouldn’t get cleaned up in case of crash. For other such cases, it could be worth having some form of assertion in StackObj destructor to make sure you don’t call it when you have a crash protection. That assert would trigger only in debug and even when there is no crash so it should help us root out such issue faster. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225
