JDK-8345784 : SIGSEGV on macOS in PcDescContainer::find_pc_desc_internal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 23,24
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • Submitted: 2024-12-09
  • Updated: 2025-06-06
  • Resolved: 2025-06-06
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.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8357468 - [asan] heap buffer overflow reported in PcDesc::pc_offset() pcDesc.hpp:57
Relates :  
JDK-8258229 - Crash in nmethod::reloc_string_for
Relates :  
JDK-8330181 - Move PcDesc cache from nmethod header
Relates :  
JDK-8331087 - Move immutable nmethod data from CodeCache
Description
When running hotspot :tier3  jtreg tests, we crashed a few times in test  compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java .
Crash occurs on macOS  (we have seen it on aarch64 and also on x86_64); issue was observed 3 times since May 2024.
Example :

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000001021ab270, pid=65996, tid=27395
#


---------------  T H R E A D  ---------------

Current thread (0x0000000116013e00):  JavaThread "C1 CompilerThread1" daemon [_thread_in_vm, id=27395, stack(0x0000000171b38000,0x0000000171d3b000) (2060K)]


Current CompileTask:
C1:1002  378       3       java.util.zip.ZipUtils::CENNAM (9 bytes)

Stack: [0x0000000171b38000,0x0000000171d3b000],  sp=0x0000000171d39e90,  free space=2055k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x827270]  PcDescContainer::find_pc_desc_internal(unsigned char*, bool, unsigned char*, PcDesc*, PcDesc*)+0x40
V  [libjvm.dylib+0x828310]  nmethod::has_code_comment(unsigned char*, unsigned char*)+0x60
V  [libjvm.dylib+0x824a0c]  nmethod::decode2(outputStream*) const+0x25c
V  [libjvm.dylib+0x824730]  nmethod::print_nmethod(bool)+0xfc
V  [libjvm.dylib+0x826238]  nmethod::post_compiled_method(CompileTask*)+0x104
V  [libjvm.dylib+0x239aa0]  ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, bool, bool, bool, bool, int)+0x3c8
V  [libjvm.dylib+0x17f530]  Compilation::compile_method()+0x24c
V  [libjvm.dylib+0x17f774]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x190
V  [libjvm.dylib+0x1810e0]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x60
V  [libjvm.dylib+0x2cd1ec]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x3b8
V  [libjvm.dylib+0x2ccc34]  CompileBroker::compiler_thread_loop()+0x3e4
V  [libjvm.dylib+0x4d9aa8]  JavaThread::thread_main_inner()+0x98
V  [libjvm.dylib+0xa3336c]  Thread::call_run()+0xc8
V  [libjvm.dylib+0x856ea0]  thread_native_entry(Thread*)+0x118
C  [libsystem_pthread.dylib+0x6f94]  _pthread_start+0x88

siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x00005ffffffffff8
Comments
> Almost definitely a duplicate of JDK-8357468. Hi [~dlong] , nice to hear that ASAN found and reported this so nicely !
06-06-2025
Almost definitely a duplicate of JDK-8357468. The hs_err files show that we accessed just before a page boundary. When I was working on JDK-8357468, I didn't think it could cause a crash because I thought the PcDesc could never be at the beginning of a mapped region, but now it can now that immutable data is allocated separately.
06-06-2025
Thanks [~mbaesken]!
10-12-2024
> Can you also attach the hs_err_file for completeness Hi [~chagedorn] I added the slightly adjusted hserr files .
10-12-2024
> please also attach the replay compilation file. Did you try to reproduce it with -XX:+ReplayCompiles? Unfortunately I do not have a replay file. I did not try with ReplayCompiles; I only checked the centrally generated test results of our automated tests. > The async-profiler case could also be JDK-8343003 or does it have the same stack trace? This case has a different stack trace : Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x84a20c] PcDescContainer::find_pc_desc_internal(unsigned char*, bool, unsigned char*, PcDesc*, PcDesc*)+0x40 V [libjvm.dylib+0x3bc988] forte_fill_call_trace_given_top(JavaThread*, ASGCT_CallTrace*, int, frame)+0x444 V [libjvm.dylib+0x3bc528] AsyncGetCallTrace+0x1e4 C [libasyncProfiler.dylib+0x1fe5c] Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int, StackContext*)+0x1a8 C [libasyncProfiler.dylib+0x4480] Profiler::recordSample(void*, unsigned long long, EventType, Event*)+0x288 C [libasyncProfiler.dylib+0x2ae88] WallClock::signalHandler(int, __siginfo*, void*)+0x14c C [libsystem_platform.dylib+0x4584] _sigtramp+0x38
10-12-2024
I executed some runs with -XX:+PrintAssembly and I frequently hit JDK-8258229. I think this is likely a duplicate of that issue.
10-12-2024
ILW = Crash during code installation, intermittent with -XX:+PrintAssembly (diagnostic flag), no workaround but disable -XX:+PrintAssembly = HLM = P3
10-12-2024
Matthias, please also attach the replay compilation file. Did you try to reproduce it with -XX:+ReplayCompiles? I assume the issue is just triggered by TestCompilerDirectivesCompatibilityFlag because it enables nmethod printing. Maybe you can run some more testing with -XX:CompileCommand=print,*::* and/or -XX:+PrintAssembly and see if that reproduces the issue? The async-profiler case could also be JDK-8343003 or does it have the same stack trace?
10-12-2024
Thanks Matthias for the additional information. I don't think we've seen this failure in our CI, yet. Can you also attach the hs_err_file for completeness?
10-12-2024
Hi [~chagedorn] we saw this issue in 2 scenarios - 1. this one (running tier3 Hotspot tests, crash always in test compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java ) 2. running the langtools jtreg tests, but with the special setup that we use the async-profiler jvmti agent In the bug itself I just mentioned the "simple" case without async-profiler jvmti agent.
09-12-2024
Hi [~mbaesken], have you seen crashes in other tests as well or only with TestCompilerDirectivesCompatibilityFlag.java?
09-12-2024