JDK-8209588 : SIGSEGV in MethodArityHistogram() with -XX:+CountCompiledCalls
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10,11,12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-08-16
  • Updated: 2020-07-27
  • Resolved: 2018-08-20
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 12
11.0.2Fixed 12 b08Fixed
Related Reports
Relates :  
JDK-8250635 - MethodArityHistogram should use Compile_lock in favour of fancy checks
Description
Call stack:
Current thread (0x00007ff0b9322000):  JavaThread "DestroyJavaVM" [_thread_in_vm, id=8195, stack(0x000000010c017000,0x000000010c117000)]

Stack: [0x000000010c017000,0x000000010c117000],  sp=0x000000010c1168e0,  free space=1022k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0xa8b8d2]  MethodArityHistogram::add_method_to_histogram(nmethod*)+0x20
V  [libjvm.dylib+0x385b57]  CodeCache::nmethods_do(void (*)(nmethod*))+0x41
V  [libjvm.dylib+0xa8b855]  MethodArityHistogram::MethodArityHistogram()+0x5d
V  [libjvm.dylib+0xa88c76]  SharedRuntime::print_call_statistics(int)+0x38c
V  [libjvm.dylib+0x62c499]  print_method_invocation_histogram()+0x3ba
V  [libjvm.dylib+0x62c6ae]  print_statistics()+0x19c
V  [libjvm.dylib+0x62ccca]  before_exit(JavaThread*)+0x35e
V  [libjvm.dylib+0xb54e2c]  Threads::destroy_vm()+0xf6
V  [libjvm.dylib+0x6d93f0]  jni_DestroyJavaVM+0xd9
C  [java+0x45a6]  JavaMain+0xa14
C  [libsystem_pthread.dylib+0x3661]  _pthread_body+0x154
C  [libsystem_pthread.dylib+0x350d]  _pthread_body+0x0
C  [libsystem_pthread.dylib+0x2bf9]  thread_start+0xd

CodeCache::nmethods_do() iterates over all existing methods. Among those might be some which are not fully constructed yet. Thus, the _method field might be zero or (even worse) contain a random value. This effect was observed previously while implementing CodeHeap State Analytics.

I would expect this bug to exist in previous versions as well.
Comments
Fix Request - This fix prevents a potential SIGSEGV when printing call statistics requested by -XX:+CountCompiledCalls - Issue and fix are relevant for non-PRODUCT builds only. - Risk is considered low for the following reasons + non-PRODUCT build only + fix makes potentially failing code less likely to be executed + code only used with -XX:+CountCompiledCalls - Fix applied cleanly to jdk-updates/jdk11u repository (as of Oct 18, 2018) - This fix is a prereq for JDK-8209950 which is intended to be downported as well.
18-10-2018
ILW = Crash in code printing diagnostic information, intermittent with debug flag -XX:+CountCompiledCalls, no workaround = MLH = P4
17-08-2018
OK, I can live with this move. It's purely philosophical anyway. CodeCache is compiler stuff, but the fix will most probably be made in sharedRuntime.cpp.
16-08-2018
Moving from hotspot/runtime -> hotspot/compiler since this appears to be CodeCache related.
16-08-2018