On Wed, 13 Apr 2022 14:53:54 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._ src/hotspot/share/prims/forte.cpp line 671: > 669: #ifndef ASSERT > 670: trace->num_frames = ticks_unknown_state; > 671: AsyncGetCallTraceCallBack cb(trace, depth, ucontext); ~Isn't [this assert](https://github.com/openjdk/jdk/blob/e245f9d2007b0a6c9962b6bf4488ba4d4ce47e92/src/hotspot/os/posix/os_posix.cpp#L1158) failing? It seems like the crash protection is only for the JFR sampler thread.~ OIC - this is only when asserts are not enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/8225
