On Tue, 30 Nov 2021 02:37:47 GMT, Coleen Phillimore <cole...@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
