JDK-8143897 : Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2015-11-24
  • Updated: 2017-11-29
  • Resolved: 2016-02-04
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
8u152Fixed 9 b107Fixed
Related Reports
Relates :  
JDK-8153267 - nmethod's exception cache not multi-thread safe
Relates :  
JDK-8164480 - Crash with assert(handler_address == SharedRuntime::compute_compiled_exc_handler(..) failed: Must be the same
Description
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/runtime.cpp:1307
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/183830.vkozlov/s/hotspot/src/share/vm/opto/runtime.cpp:1307), pid=31672, tid=5324
#  assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-20151123183830.vkozlov.8143307-b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-fastdebug-20151123183830.vkozlov.8143307-b00, compiled mode, compressed oops, g1 gc, linux-aarch64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /export/local/aurora/sandbox/results/medrec_domain/core.31672)
#
# An error report file with more information is saved as:
# /export/local/aurora/sandbox/results/medrec_domain/hs_err_pid31672.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Comments
Two instance of crashes are reported. ExceptionCache(heap) and ExceptionHandlerTable(heap) content in core file are consistent, failure is due to weak memory ordering issue. 1st Instance: Method Name:doGetTransactionalEntityManager Exception Cache p *nm->_exception_cache $2 = {<CHeapObj<(MemoryType)4>> = {<AllocatedObj> = { _vptr.AllocatedObj = 0x7f871b4690 <vtable for ExceptionCache+16>}, <No data fields>}, _exception_type = 0x80016d038, _pc = {0x7f79c96d5c "\375\003", 0xf1f1f1f1f1f1f1f1 <error: Cannot access memory at address 0xf1f1f1f1f1f1f1f1> <repeats 15 times>}, _handler = {0x7f79c96e18 "\340\003\023\252\b", 0xf1f1f1f1f1f1f1f1 <error: Cannot access memory at address 0xf1f1f1f1f1f1f1f1> <repeats 15 times>}, _count = 1, _next = 0x0} Exception PC pc 0x7f79c96d5c (gdb) x /10gx 0x7f79c96b10 + 1944 0x7f79c972a8: 0x0000004c00000001 0xffffffff00000000 0x7f79c972b8: 0x0000000000000188 0x0000006000000001 0x7f79c972c8: 0xffffffff00000000 0x0000000000000180 0x7f79c972d8: 0x0000007000000001 0xffffffff00000000 0x7f79c972e8: 0x0000000000000178 0x0000009000000001 (gdb) 0x7f79c972f8: 0xffffffff00000000 0x0000000000000160 0x7f79c97308: 0x000000ac00000001 0xffffffff00000000 0x7f79c97318: 0x0000000000000168 0x000000b800000001 0x7f79c97328: 0xffffffff00000000 0x0000000000000170 0x7f79c97338: 0x000000c800000001 0xffffffff00000000 (gdb) 0x7f79c97348: 0x0000000000000158 0x0000011c00000001 0x7f79c97358: 0xffffffff00000000 0x0000000000000150 Exception pc offset p pc - 0x7f79c96cb0 Handler address $7 = (unsigned char *) 0xac <error: Cannot access memory at address 0xac> (gdb) x 0x7f79c96cb0 +0x168 0x7f79c96e18: mov x0, x19 all data are consistent Second Instance method name "getResponseHeaders" Exception Cache p *nm->_exception_cache $6 = {<CHeapObj<(MemoryType)4>> = {<AllocatedObj> = { _vptr.AllocatedObj = 0x7f93dff740 <vtable for ExceptionCache+16>}, <No data fields>}, _exception_type = 0x7f75481638, _pc = {0x7f780c4de0 "\004", 0x7f780c4ca0 "\004", 0xf1f1f1f1f1f1f1f1 <error: Cannot access memory at address 0xf1f1f1f1f1f1f1f1> <repeats 14 times>}, _handler = {0x7f780c6380 "\344\003\035\252\200", 0x7f780c63c8 "\344\v", <incomplete sequence \371\200>, 0xf1f1f1f1f1f1f1f1 <error: Cannot access memory at address 0xf1f1f1f1f1f1f1f1> <repeats 14 times>}, _count = 2, _next = 0x0} Exception PC (gdb) p pc $7 = (address) 0x7f780c4ca0 "\004" Exception hanler Table (gdb) x /10gx 0x7f780c4790 +22232 0x7f780c9e68: 0x000000ac00000001 0xffffffff00000000 0x7f780c9e78: 0x0000000000001a80 0x0000010000000001 0x7f780c9e88: 0xffffffff00000000 0x0000000000001a20 0x7f780c9e98: 0x000001f800000001 0xffffffff00000000 0x7f780c9ea8: 0x0000000000001a18 0x0000030000000001 (gdb) 0x7f780c9eb8: 0xffffffff00000000 0x0000000000001a28 0x7f780c9ec8: 0x0000044000000001 0xffffffff00000000 0x7f780c9ed8: 0x00000000000019e0 0x000005b000000001 0x7f780c9ee8: 0xffffffff00000000 0x0000000000001a78 0x7f780c9ef8: 0x000006f000000001 0xffffffff00000000 (gdb) 0x7f780c9f08: 0x0000000000001a70 0x000007a000000001 0x7f780c9f18: 0xffffffff00000000 0x0000000000001a88 0x7f780c9f28: 0x0000085c00000001 0xffffffff00000000 0x7f780c9f38: 0x0000000000001a68 0x0000096c00000001 0x7f780c9f48: 0xffffffff00000000 0x0000000000001a60 (gdb) 0x7f780c9f58: 0x00000cc400000001 0xffffffff00000000 0x7f780c9f68: 0x00000000000019cc 0x00000ce400000001 0x7f780c9f78: 0xffffffff00000000 0x00000000000019d8 0x7f780c9f88: 0x00000d1c00000001 0xffffffff00000000 0x7f780c9f98: 0x00000000000019d4 0x000000bc Exception pc offset (gdb) x pc -0x7f780c49a0 0x300: Cannot access memory at address 0x300 Handler address (gdb) x 0x0000000000001a28 + 0x7f780c49a0 0x7f780c63c8: ldr x4, [sp,#16] (gdb) Exception table content and cache content are consistent
30-01-2016