8u152 sigsegv in CounterDecay::do_method during VMThead safepoint processing

Mon Jan 22 15:36:16 UTC 2018

Hi all,

Are there any known issues with this method crashing the JVM? Here's a
(slightly redacted) snippet from the hs_err log:

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x00002b14765b7210, pid=140880,
tid=0x00002b149a643700

#

# JRE version: Java(TM) SE Runtime Environment (8.0_152-b16) (build
1.8.0_152-b16)

# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.152-b16 mixed mode
linux-amd64 compressed oops)

# Problematic frame:

# V  [libjvm.so+0x49c210]  CounterDecay::do_method(Method*)+0x0

#

# Core dump written. Default location: <path> or core.140880

#

# If you would like to submit a bug report, please visit:

#   http://bugreport.java.com/bugreport/crash.jsp

#

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

Current thread (0x00002b147cb12800):  VMThread [stack:
0x00002b149a543000,0x00002b149a644000]
[id=140909]

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

Registers:

RAX=0x0000000000000000, RBX=0x0000000000000001, RCX=0x00002b156839ca18,
RDX=0x00002b156799fc68

RSP=0x00002b149a6429b8, RBP=0x00002b149a6429e0, RSI=0x00002b14765b7210,
RDI=0x0000001a00190005

R8 =0x0000000000000010, R9 =0x0000000000000001, R10=0x0000000000000000,
R11=0x0000000000000001

R12=0x0000000000000007, R13=0x00000007c03c8428, R14=0x00002b14765b7210,
R15=0x0000000000000000

RIP=0x00002b14765b7210, EFLAGS=0x0000000000010202,
CSGSFS=0x0000000000000033, ERR=0x0000000000000004

  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00002b149a6429b8)

0x00002b149a6429b8:   00002b147675e83d 0000000000000060

0x00002b149a6429c8:   00002b149a642a10 0000000000000000

0x00002b149a6429d8:   0000000000000000 00002b149a642a00

0x00002b149a6429e8:   00002b14765b3cd1 40590bbbbbbbbbbc

0x00002b149a6429f8:   00002b14770db352 00002b149a642a50

0x00002b149a642a08:   00002b1476adfbd6 00000000018f0100

0x00002b149a642a18:   0000000000000000 00002b149a642a40

0x00002b149a642a28:   00002b1476ba2100 431bde82d7b634db

0x00002b149a642a38:   00002b14f9ce9800 431bde82d7b634db

0x00002b149a642a48:   00002b14f9ce9800 00002b149a642b00

0x00002b149a642a58:   00002b1476ae08a6 00002b14770e6140

0x00002b149a642a68:   00002b149a642aa0 00002b147709ef83

0x00002b149a642a78:   0000000000ae12f0 000000307cb12800

0x00002b149a642a88:   0000000000000000 00000040000003e8

0x00002b149a642a98:   0000001a0000001a 00002b14ce44b580

0x00002b149a642aa8:   00002b1478ccda09 00002b1478cbb5d0

0x00002b149a642ab8:   00002b1400000000 00002b14ce44b5d0

0x00002b149a642ac8:   00002b14ce44b580 00002b14770db3d8

0x00002b149a642ad8:   0000000000000000 0000000000000000

0x00002b149a642ae8:   00002b14770db3d8 00002b147cb12800

0x00002b149a642af8:   00002b14770e5950 00002b149a642ca0

0x00002b149a642b08:   00002b1476bf22ef 00002b149a642b20

0x00002b149a642b18:   00002b149a642c30 00002b149a642b28

0x00002b149a642b28:   6e69747563657845 65706f204d562067

0x00002b149a642b38:   203a6e6f69746172 6c6f43636e493147

0x00002b149a642b48:   506e6f697463656c 6e6f640065737561

0x00002b149a642b58:   6e6f64206e6f0065 0000000000000065

0x00002b149a642b68:   0000001577100ce0 0000000000000000

0x00002b149a642b78:   00002b14770ae164 00002b1476116e40

0x00002b149a642b88:   0000000000000148 00002b147cb12800

0x00002b149a642b98:   0000000000000002 00002b149a642c40

0x00002b149a642ba8:   00002b1475e08a40 00002b149a543000

Instructions: (pc=0x00002b14765b7210)

0x00002b14765b71f0:   55 31 c0 48 89 e5 c9 c3 90 90 90 90 90 90 90 90

0x00002b14765b7200:   55 b8 04 00 00 00 48 89 e5 c9 c3 90 90 90 90 90

0x00002b14765b7210:   48 8b 4f 18 55 48 89 e5 48 85 c9 74 28 8b 51 08

0x00002b14765b7220:   89 d0 c1 e8 03 89 c6 d1 fe 85 c0 7e 09 85 f6 b8

Register to memory mapping:

RAX=0x0000000000000000 is an unknown value

RBX=0x0000000000000001 is an unknown value

RCX=0x00002b156839ca18 is an unknown value

RDX=0x00002b156799fc68 is pointing into metadata

RSP=0x00002b149a6429b8 is an unknown value

RBP=0x00002b149a6429e0 is an unknown value

RSI=0x00002b14765b7210: <offset 0x49c210> in
<path>/jre/lib/amd64/server/libjvm.so
at 0x00002b147611b000

RDI=0x0000001a00190005 is an unknown value

R8 =0x0000000000000010 is an unknown value

R9 =0x0000000000000001 is an unknown value

R10=0x0000000000000000 is an unknown value

R11=0x0000000000000001 is an unknown value

R12=0x0000000000000007 is an unknown value

R13=0x00000007c03c8428 is pointing into metadata

R14=0x00002b14765b7210: <offset 0x49c210> in
<path>/jre/lib/amd64/server/libjvm.so
at 0x00002b147611b000

R15=0x0000000000000000 is an unknown value

Stack: [0x00002b149a543000,0x00002b149a644000],  sp=0x00002b149a6429b8,
free space=1022k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)

V  [libjvm.so+0x49c210]  CounterDecay::do_method(Method*)+0x0

V  [libjvm.so+0x498cd1]  NonTieredCompPolicy::do_safepoint_work()+0x91

V  [libjvm.so+0x9c4bd6]  SafepointSynchronize::do_cleanup_tasks()+0x76

V  [libjvm.so+0x9c58a6]  SafepointSynchronize::begin()+0x406

V  [libjvm.so+0xad72ef]  VMThread::loop()+0x1bf

V  [libjvm.so+0xad7770]  VMThread::run()+0x70

V  [libjvm.so+0x92d8d8]  java_start(Thread*)+0x108

VM_Operation (0x00002b15140011a0): G1IncCollectionPause, mode: safepoint,
requested by thread 0x00002b14f9bb8000

This is on a Debian Wheezy linux machine running Xeon Broadwell cores.  The
reason I mention this part is a quick google did show
https://bugs.openjdk.java.net/browse/JDK-8156721 but that JBS is for a
different platform (with an overclocked CPU, apparently) and it's marked
Incomplete.

This crash was observed on about 17 separate JVMs (different hosts) at
about the same time, all running the same application code after about 3
weeks of uptime.

I can provide more details if you'd like but wanted to see if this is a
known (but rarely witnessed) bug.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180122/fe24bb45/attachment-0001.html>