RFR: 8265150: AsyncGetCallTrace crashes on ResourceMark

[Thomas Stuefe]

On Tue, 30 Nov 2021 02:37:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change seems to keep the test case in the bug from crashing in the ResourceMark destructor.  We have a ResourceMark during stack walking in AsyncGetCallTrace.  Also RegisterMap during jvmti shouldn't process oops, fix care of @fisk.
> Testing tier1-6 in progress.

> > > Hi Coleen,
> > > This bypasses the currently observed problem, but we still have a fundamentally unsafe mechanism in use here. :(
> > > Thanks, David
> > 
> > 
> > Does AsyncGetCallTrace get triggered asynchronously via signal?
> 
> Yes:
> 
> ```v
> C [libasyncProfiler.so+0x89b4] Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int)+0xd4
> C [libasyncProfiler.so+0x9242] Profiler::recordSample(void*, unsigned long long, int, Event*)+0xd2 
> C [libasyncProfiler.so+0x34f2c] PerfEvents::signalHandler(int, siginfo_t*, void*)+0x8c 
> ```

What you could do is keep (on demand only) a secondary resource area per thread. On entering a context that may have been called by a signal handler, and with the current resource area in an unknown state, swap the current resource area pointer in Thread with that prepared secondary resource area, and upon leaving swap back. That way you never touch the original resource area.

Kind of like double buffering for signal contexts.

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

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