JDK-8209950 : SIGBUS in CodeHeapState::print_names()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: sparc
  • Submitted: 2018-08-24
  • Updated: 2021-08-31
  • Resolved: 2018-08-30
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 b10Fixed
Related Reports
Relates :  
JDK-8217465 - [REDO] - Optimize CodeHeap Analytics
Relates :  
JDK-8217250 - Optimize CodeHeap Analytics
Relates :  
JDK-8250635 - MethodArityHistogram should use Compile_lock in favour of fancy checks
Relates :  
JDK-8200366 - SIGSEGV in CodeHeapState::print_names()
Relates :  
JDK-8216314 - SIGILL in CodeHeapState::print_names()
Description
This is similar to JDK-8200366 but happens on SPARC and that is why it may hit SIGBUS instead of SIGSEGV.

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0xffffffff7c920e14, pid=243, tid=12
#
# JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug build 12-internal+0-jdk12-jdk.277)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 12-internal+0-jdk12-jdk.277, compiled mode, compressed oops, g1 gc, solaris-sparc)
# Problematic frame:
# V  [libjvm.so+0xd20e14]  void CodeHeapState::print_names(outputStream*,CodeHeap*)+0x924
#

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

Current thread (0x00000001007b5000):  JavaThread "Attach Listener" daemon [_thread_in_vm, id=12, stack(0xffffffff3ee00000,0xffffffff3ef00000)]

Stack: [0xffffffff3ee00000,0xffffffff3ef00000],  sp=0xffffffff3eeff130,  free space=1020k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xd20e14]  void CodeHeapState::print_names(outputStream*,CodeHeap*)+0x924
V  [libjvm.so+0xd0df7c]  void CodeCache::print_names(outputStream*)+0xac
V  [libjvm.so+0xda67f4]  void CompileBroker::print_heapinfo(outputStream*,const char*,const char*)+0x3c4
V  [libjvm.so+0xf2f490]  void DCmd::parse_and_execute(DCmdSource,outputStream*,const char*,char,Thread*)+0x440
V  [libjvm.so+0x9766d4]  int jcmd(AttachOperation*,outputStream*)+0x34
V  [libjvm.so+0x977268]  void attach_listener_thread_entry(JavaThread*,Thread*)+0x438
V  [libjvm.so+0x1f93a04]  void JavaThread::thread_main_inner()+0x2e4
V  [libjvm.so+0x1f936f0]  void JavaThread::run()+0x650
V  [libjvm.so+0x1bc9dfc]  thread_native_entry+0x2dc
Comments
Fix Request - This fix avoids code in CodeHeap State Analytics to run into a SIGSEGV by preventing it to see an inconsistent code heap state. - The same checking code is used in MethodArityHistogram() (see JDK-8209588). - The non-trivial check is factored out into a separate function which is then called from both sites. - The fix heals both, PRODUCT and not-PRODUCT, builds. - The risk is considered low for the following reasons + fix prevents potentially failing code from being executed if the risk of failure exists. + code only used with -XX:+CountCompiledCalls or must be activated via UL. - Fix applied cleanly to jdk-updates/jdk11u repository (as of Oct 18, 2018) if JDK-8209588 was applied before. - This fix requires JDK-8209588 to be downported as well.
18-10-2018
Most recent web rev: http://cr.openjdk.java.net/~lucy/webrevs/8209950.01/
04-09-2018
URL: http://hg.openjdk.java.net/jdk/jdk/rev/9183040e34d8 User: lucy Date: 2018-08-30 09:51:25 +0000
30-08-2018
BTW, there is a RFR out since Monday, 12:30 UTC.
28-08-2018
ILW = Crash while printing code heap statistics, intermittent with diagnostics (jcmd), no workaround (but can disable diagnostic option) = HLM = P3
28-08-2018
What a coincidence! While using the code fixed with JDK-8209588, I ran into another potential NULL/uninitialized pointer issue. It is located in sharedRuntime.cpp, but the (obviously incomplete) checking code was copied from codeHeapState.cpp. I have a fix locally on my machines, but there is no webrev, local build, or test coverage yet. The fix for JDK-8209588 has to be extended like if ((nm != NULL) && (m != NULL) && (m->signature() != NULL) && !nm->is_zombie() && !nm->is_not_installed() && os::is_readable_pointer(m) && os::is_readable_pointer(m->constants()) && os::is_readable_pointer(m->signature())) { and the same if has to go into codeHeapState.cpp::print_names(). Unfortunately, I will be on the road travelling for the entire weekend (leaving home in 7 hours & need some sleep before). I will work on a fix first thing Monday morning.
24-08-2018
Some of latest output: [stress.process.err] Compiled method (c2) 969032 30124 org.apache.derby.impl.sql.compile.ConstraintDefinitionNode::getBackingIndexName (22 bytes) [stress.process.err] total in heap [0xffffffff6eda6210,0xffffffff6eda6720] = 1296 [stress.process.err] relocation [0xffffffff6eda6398,0xffffffff6eda63a8] = 16 [stress.process.err] main code [0xffffffff6eda63c0,0xffffffff6eda6580] = 448 [stress.process.err] stub code [0xffffffff6eda6580,0xffffffff6eda65d0] = 80 [stress.process.err] oops [0xffffffff6eda65d0,0xffffffff6eda65d8] = 8 [stress.process.err] metadata [0xffffffff6eda65d8,0xffffffff6eda65e0] = 8 [stress.process.err] scopes data [0xffffffff6eda65e0,0xffffffff6eda6620] = 64 [stress.process.err] scopes pcs [0xffffffff6eda6620,0xffffffff6eda6700] = 224 [stress.process.err] dependencies [0xffffffff6eda6700,0xffffffff6eda6708] = 8 [stress.process.err] handler table [0xffffffff6eda6708,0xffffffff6eda6720] = 24 [stress.process.err] Compiled method (c2) 969033 30124 org.apache.derby.impl.sql.compile.ConstraintDefinitionNode::getBackingIndexName (22 bytes) [stress.process.err] total in heap [0xffffffff6eda6210,0xffffffff6eda6720] = 1296 [stress.process.err] relocation [0xffffffff6eda6398,0xffffffff6eda63a8] = 16 [stress.process.err] main code [0xffffffff6eda63c0,0xffffffff6eda6580] = 448 [stress.process.err] stub code [0xffffffff6eda6580,0xffffffff6eda65d0] = 80 [stress.process.err] oops [0xffffffff6eda65d0,0xffffffff6eda65d8] = 8 [stress.process.err] metadata [0xffffffff6eda65d8,0xffffffff6eda65e0] = 8 [stress.process.err] scopes data [0xffffffff6eda65e0,0xffffffff6eda6620] = 64 [stress.process.err] scopes pcs [0xffffffff6eda6620,0xffffffff6eda6700] = 224 [stress.process.err] dependencies [0xffffffff6eda6700,0xffffffff6eda6708] = 8 [stress.process.err] handler table [0xffffffff6eda6708,0xffffffff6eda6720] = 24 [stress.process.err] Current thread is 12 [stress.process.err] Dumping core ...
24-08-2018