RFR: 8284828: Use `os::ThreadCrashProtection` to protect AsyncGetCallTrace from crashing [v4]

[Thomas Stuefe]

On Thu, 14 Apr 2022 10:16:28 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> 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.

Darn, @luhenry is right. And the more I think about this, the more doubts I get about this approach. 

We have only one other subsystem that does this kind of wholesale catching of error signals and then unwinding the stack (JFR) and presumably they fine-combed their coding and are sure exactly what they do under the sigjmp guard. Are we also certain? 

Because as long as we cannot guarantee that we really don't use RAII, or actually anything needing cleanup (e.g. dynamic memory allocation), and that we don't accidentally abandon a lock, we cannot use sigjmp. This precludes use of resource area, and had that not been an issue? We cannot even use malloc here.

Under these circumstances, crashing may be better than not crashing, since not crashing could leave the thread in a corrupted state or in a deadlock.

I think the safer approach, albeit much more work intensive, would be to make sure we do not crash. Starting with removing RA allocation. I tried to make RA signal safe with https://bugs.openjdk.java.net/browse/JDK-8282405, but that got totally stuck, so better just remove it altogether from AGCT. Over using SafeFetch or plain defensive coding to avoid crashing.

Sorry for this. If I'm wrong, please someone correct me. This looked like a simple solution at first.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8225