JDK-8059100 : SIGSEGV VirtualMemoryTracker::remove_released_region
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8u40
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-09-25
  • Updated: 2015-06-03
  • Resolved: 2014-10-11
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 8 JDK 9
8u40Fixed 9 b37Fixed
Related Reports
Duplicate :  
JDK-8062377 - SIGSEGV VirtualMemoryTracker::add_reserved_region
Duplicate :  
JDK-8059104 - SIGSEGV VirtualMemoryTracker::remove_uncommitted_region
Relates :  
JDK-8058606 - [TESTBUG] Detailed Native Memory Tracking (NMT) data is not verified as output at VM exit
Relates :  
JDK-8061996 - NMT2 overflows MallocSiteTable too much
Description
The hs_err head is:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x01024592, pid=16016, tid=3086367632
#
# JRE version: Java(TM) SE Runtime Environment (8.0_40-b07) (build 1.8.0_40-ea-b07)
# Java VM: Java HotSpot(TM) Server VM (25.40-b11 mixed mode linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x89e592]  VirtualMemoryTracker::remove_released_region(unsigned char*, unsigned int)+0x72
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

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

Current thread (0x65489000):  JavaThread "DestroyJavaVM" [_thread_in_vm, id=16020, stack(0xb7f13000,0xb7f64000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000000

Registers:
EAX=0x00000000, EBX=0x011284cc, ECX=0x01121fc8, EDX=0x01151bc4
ESP=0xb7f63178, EBP=0xb7f631f8, ESI=0xb7f6322b, EDI=0xb7f631bc
EIP=0x01024592, EFLAGS=0x00010216, CR2=0x00000000

Top of Stack: (sp=0xb7f63178)
0xb7f63178:   00000001 00fd2b90 09cde228 01121fc8
0xb7f63188:   ffffffff 00fd280e 09cde220 00000000
0xb7f63198:   09cde228 011284cc 00000000 00000000
0xb7f631a8:   b7f631f8 00fa1299 01156130 010bb42f
0xb7f631b8:   0073cc97 6596e000 00081000 01121fc8
0xb7f631c8:   00000000 00000000 00000000 00000000
0xb7f631d8:   00000000 00000000 00000000 0000000f
0xb7f631e8:   01150500 011284cc b7f6322b 09dc0c00 

Instructions: (pc=0x01024592)
0x01024572:   00 89 4d cc c7 45 d0 00 00 00 00 c7 45 d4 00 00
0x01024582:   00 00 c7 45 ec 0f 00 00 00 c6 45 f0 00 8d 7d c4
0x01024592:   8b 10 89 7d 88 57 50 ff 52 14 83 c4 0c 89 c6 8b
0x010245a2:   45 0c 50 8b 45 08 50 56 e8 21 fb ff ff 31 ff 83 

Register to memory mapping:

EAX=0x00000000 is an unknown value
EBX=0x011284cc: <offset 0x9a24cc> in /export/local/aurora/CommonData/jdk/jre/lib/i386/server/libjvm.so at 0x00786000
ECX=0x01121fc8: <offset 0x99bfc8> in /export/local/aurora/CommonData/jdk/jre/lib/i386/server/libjvm.so at 0x00786000
EDX=0x01151bc4: <offset 0x9cbbc4> in /export/local/aurora/CommonData/jdk/jre/lib/i386/server/libjvm.so at 0x00786000
ESP=0xb7f63178 is an unknown value
EBP=0xb7f631f8 is an unknown value
ESI=0xb7f6322b is an unknown value
EDI=0xb7f631bc is an unknown value


Stack: [0xb7f13000,0xb7f64000],  sp=0xb7f63178,  free space=320k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x89e592]  VirtualMemoryTracker::remove_released_region(unsigned char*, unsigned int)+0x72
V  [libjvm.so+0x84e80c]  Thread::~Thread()+0xbc
V  [libjvm.so+0x8ac935]  VMThread::~VMThread()+0x25
V  [libjvm.so+0x8ab506]  VMThread::destroy()+0x26
V  [libjvm.so+0x855c2a]  Threads::destroy_vm()+0xfa
V  [libjvm.so+0x524de2]  jni_DestroyJavaVM+0xb2
C  [libjli.so+0x6f97]  JavaMain+0x2a7
C  [libpthread.so.0+0x5869]
C  [libc.so.6+0xd413e]  clone+0x5e
Comments
Catching this in the debugger, one thread has shutdown NMT while another thread (because of MallocSiteTable overflow) sets the NMT level to summary. The order of events: 1. prints NMT statistics and calls shutdown 2 checks level (still at detail) 1 set nmt level = minimal and deletes _reserved_regions 2 ... overflows detail table or something 1. runs code to shut down the jvm 2 sets NMT tracking level to summary 1. calls ~Thread dtor which calls remove_released_regions 1. since level is summary, tries to get the _reserved_regions data The NMT code had untested support for increasing the NMT level that isn't supported in the product. Disallowing increasing NMT level (or ignoring increase in NMT level), fixes this crash. The fix for this problem also removes the shutdown() call in final_report() and changes final_report() to create a baseline. The code assumed that creating baseline was too risky to put in the hs_err, so modified the malloc data in place then called shutdown(). This is actually risky for other threads running may see the modified value. Also, the final_report code isn't calling malloc() and doesn't seem risky for error situations. It allocates a stack object and copies the baseline in and prints it. It's not likely to fail.
09-10-2014