JDK-8329103 : assert(!thread->in_asgct()) failed during multi-mode profiling
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 11.0.23,17.0.9,21,22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-03-26
  • Updated: 2024-08-28
  • Resolved: 2024-04-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17 JDK 21 JDK 23
11.0.25Fixed 17.0.13Fixed 21.0.5Fixed 23 b17Fixed
Related Reports
Relates :  
JDK-8304725 - AsyncGetCallTrace can cause SIGBUS on M1
Relates :  
JDK-8339133 - [8u] Profiler crashes at guarantee(is_result_safe || is_in_asgct()): unsafe access to zombie method
Description
Debug JVM crashes on the following assertion if CPU and Wall clock profiling modes are enabled together. It may also crash if two profiler instances are running simultaneously.

#  assert(!thread->in_asgct()) failed: invariant

Stack: [0x00007fcc35fe4000,0x00007fcc360e5000],  sp=0x00007fcc360e0230,  free space=1008k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xc5cd51]  AsyncGetCallTrace+0x261
C  [libasyncProfiler.so+0x16775]  Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int, StackContext*)+0xb5
C  [libasyncProfiler.so+0x24927]  Profiler::recordSample(void*, unsigned long long, EventType, Event*)+0x837
C  [libasyncProfiler.so+0x256d8]  PerfEvents::signalHandler(int, siginfo_t*, void*)+0xd8
C  [libpthread.so.0+0x118e0]
V  [libjvm.so+0xc6b5c7]  frame::frame(long*, long*, long*, unsigned char*)+0x47
V  [libjvm.so+0xc693cc]  frame::safe_for_sender(JavaThread*)+0x46c
V  [libjvm.so+0xc5bb7c]  vframeStreamForte::forte_next()+0x5c
V  [libjvm.so+0xc5c369]  forte_fill_call_trace_given_top(JavaThread*, ASGCT_CallTrace*, int, frame)+0x3f9
V  [libjvm.so+0xc5cd9e]  AsyncGetCallTrace+0x2ae
C  [libasyncProfiler.so+0x16775]  Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int, StackContext*)+0xb5
C  [libasyncProfiler.so+0x24927]  Profiler::recordSample(void*, unsigned long long, EventType, Event*)+0x837
C  [libasyncProfiler.so+0x25772]  WallClock::signalHandler(int, siginfo_t*, void*)+0x42

This is a regression that appeared after JDK-8304725 which added the above assertion thus making AsyncGetCallTrace no longer reentrant. However, there is nothing in AGCT implementation besides this assertion that prevents it from being reentrant.
There were no issues when running multi-mode profiling with product JVM builds.
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk11u-dev/pull/2812 Date: 2024-06-24 14:58:33 +0000
09-07-2024
[jdk11u-fix-request] Approval Request from Jaroslav Bachorik Please, approve this backport of a fix for ASGCT reentrancy. The change is trivial and affects only ASGCT related execution.
01-07-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2632 Date: 2024-06-24 14:22:03 +0000
24-06-2024
[jdk17u-fix-request] Approval Request from Jaroslav Bachorik Please, approve this backport of a fix for ASGCT reentrancy. The change is trivial and affects only ASGCT related execution.
24-06-2024
[jdk21u-fix-request] Approval Request from Jaroslav Bachorik Please, approve this backport of a fix for ASGCT reentrancy. The change is trivial and affects only ASGCT related execution.
24-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/790 Date: 2024-06-24 14:05:36 +0000
24-06-2024
Changeset: 6b1b0e9d Author: Andrei Pangin <apangin@openjdk.org> Committer: Serguei Spitsyn <sspitsyn@openjdk.org> Date: 2024-04-02 04:30:26 +0000 URL: https://git.openjdk.org/jdk/commit/6b1b0e9d45eb56f88398e2a6bca0d90c03112eaa
02-04-2024
[~dholmes] You are right, there were issues in the past. They have been fixed since then, though.
28-03-2024
[~apangin] wasn't JDK-8282405 trying to address one reason why ACGT is not async-signal-safe?
28-03-2024
[~dholmes] AGCT looks async-signal-safe to me with the change in the proposed pull request. Or are you aware of a reason why it's not?
27-03-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18504 Date: 2024-03-27 01:02:41 +0000
27-03-2024
> there is nothing in AGCT implementation besides this assertion that prevents it from being reentrant. You means beside the fact it is already not async-signal-safe?
26-03-2024
ILW=HLL=P4
26-03-2024