JDK-8134566 : java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java crashes in monitor synchronization code
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2015-08-27
  • Updated: 2015-09-18
  • Resolved: 2015-08-27
Related Reports
Duplicate :  
JDK-8049304 - race between VM_Exit and _sync_FutileWakeups->inc()
Relates :  
JDK-8136988 - EXCEPTION_PRIV_INSTRUCTION
Description
In hs-comp nightly testing:

#  SIGSEGV (0xb) at pc=0xf69c1aa4, pid=21007, tid=0x000064a0
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-20150825060115.tohartma.8075805-b00)
# Java VM: Java HotSpot(TM) Server VM (1.9.0-internal-fastdebug-20150825060115.tohartma.8075805-b00, compiled mode, g1 gc, linux-x86)
# Problematic frame:
# V  [libjvm.so+0xdedaa4]  ObjectMonitor::EnterI(Thread*)+0x564

V  [libjvm.so+0xdedaa4]  ObjectMonitor::EnterI(Thread*)+0x564
V  [libjvm.so+0xdee69d]  ObjectMonitor::enter(Thread*)+0x52d
V  [libjvm.so+0x1002573]  ObjectSynchronizer::fast_enter(Handle, BasicLock*, bool, Thread*)+0x1f3
V  [libjvm.so+0x9f1928]  InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*)+0x1d8
j  java.lang.invoke.BoundMethodHandle$SpeciesData.get(Ljava/lang/String;)Ljava/lang/invoke/BoundMethodHandle$SpeciesData;+18
j  java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(Ljava/lang/invoke/LambdaForm$BasicType;)Ljava/lang/invoke/BoundMethodHandle$SpeciesData;+47
j  java.lang.invoke.LambdaFormEditor.newSpeciesData(Ljava/lang/invoke/LambdaForm$BasicType;)Ljava/lang/invoke/BoundMethodHandle$SpeciesData;+5
j  java.lang.invoke.LambdaFormEditor.bindArgumentForm(I)Ljava/lang/invoke/LambdaForm;+80
j  java.lang.invoke.LambdaFormEditor.bindArgumentF(Ljava/lang/invoke/BoundMethodHandle;IF)Ljava/lang/invoke/BoundMethodHandle;+44
j  java.lang.invoke.BoundMethodHandle.bindArgumentF(IF)Ljava/lang/invoke/BoundMethodHandle;+7
j  java.lang.invoke.MethodHandles.insertArgumentPrimitive(Ljava/lang/invoke/BoundMethodHandle;ILjava/lang/Class;Ljava/lang/Object;)Ljava/lang/invoke/BoundMethodHandle;+87
j  java.lang.invoke.MethodHandles.insertArguments(Ljava/lang/invoke/MethodHandle;I[Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;+62
j  TestMethods$6.getMH(Ljava/util/Map;LTestMethods$Kind;)Ljava/lang/invoke/MethodHandle;+71
J 76249 C2 TestMethods.getTestCaseMH(Ljava/util/Map;LTestMethods$Kind;)Ljava/lang/invoke/MethodHandle; (92 bytes) @ 0xf2b1f17c [0xf2b1f120+0x5c]
J 81930 C2 LFMultiThreadCachingTest.lambda$doTest$0(Ljava/util/concurrent/CyclicBarrier;Ljava/util/concurrent/ConcurrentLinkedQueue;Ljava/util/Map;LTestMethods$Kind;Ljava/util/Map;Ljava/util/concurrent/CountDownLatch;)V (62 bytes) @ 0xf47881ec [0xf4788180+0x6c]
J 81929 C2 LFMultiThreadCachingTest$$Lambda$34.run()V (32 bytes) @ 0xf2add604 [0xf2add5a0+0x64]
J 1050 C2 java.lang.Thread.run()V (17 bytes) @ 0xf2b78928 [0xf2b78900+0x28]
v  ~StubRoutines::call_stub
V  [libjvm.so+0xa15b8e]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x205e
V  [libjvm.so+0xe17ce4]  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x24
V  [libjvm.so+0xa108ee]  JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x67e
V  [libjvm.so+0xa1121d]  JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x9d
V  [libjvm.so+0xafe474]  thread_entry(JavaThread*, Thread*)+0xc4
V  [libjvm.so+0x1054a82]  JavaThread::thread_main_inner()+0x202
V  [libjvm.so+0x1054dd6]  JavaThread::run()+0x2e6
V  [libjvm.so+0xe0f3f0]  java_start(Thread*)+0xe0
C  [libpthread.so.0+0x6f12]  start_thread+0xd2
C  [libc.so.6+0xeaebe]  clone+0x5e
Comments
The core file in the test execution directory was captured during the timeout artifact gathering phase and is NOT the core file from the SIGSEGV crash described by the hs_err_pid file. I've poked around the test suite's artifacts and I can't find another core file from this test suite run. Normally, I'd like to extract the stack from the shutdown thread in order to prove that the shutdown procedure was past the point where the JVM stat data has been freed, but I can't do that without a core file. I'm going to have to rely on the "VM state:at safepoint (shutting down)" line from the hs_err_pid file as proof that we're executing the VM shutdown VM operation. I'm closing this bug as a duplicate of JDK-8049304.
27-08-2015
Based on the log file and the test execution directory contents it looks like the test timed out, the test harness was gathering timeout artifacts (jstack and pstack output), and the VM under test started to shutdown when it crashed due to a SIGSEGV.
27-08-2015
Looks like the VM is shutting down (from hs_err_pid): VM state:at safepoint (shutting down) so this looks like another instance of the following bug: JDK-8049304 race between VM_Exit and _sync_FutileWakeups->inc() I'll poke around a bit more before closing this one as a duplicate.
27-08-2015