JDK-8149898 : mach5 tier-1: vm crashed intermittently in java/util/TimeZone/Bug6772689.java
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • CPU: generic
  • Submitted: 2016-02-16
  • Updated: 2016-03-15
  • Resolved: 2016-03-15
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 9
9Resolved
Related Reports
Duplicate :  
JDK-8150804 - C2 Compilation fails with assert(_base >= OopPtr && _base <= AryPtr) failed: Not a Java pointer
Relates :  
JDK-8151798 - Mark java/util/TimeZone/Bug6772689.java as intermittently failing and demote to tier2
Relates :  
JDK-8150135 - SIGSEGV in G1CollectedHeap::is_scavengable during new nmethod creation
Description
This has been seen on Mac OS x.

Please refer to following snippet of hs_err log. It looks related with  sun.util.calendar.AbstractCalendar::getTime 
---------------  S U M M A R Y ------------

Command Line: -ea -esa -Xmx512m -Djava.security.policy=file:/scratch/jenkins/workspace/9-dev-tier1-mac/JTwork/jtreg.policy com.sun.javatest.regtest.agent.AgentServer -allowSetSecurityManager -port 50923

Host: MacPro6,1 x86_64 3700 MHz, 8 cores, 16G, Darwin 13.4.0
Time: Tue Feb 16 01:58:17 2016 GMT elapsed time: 662 seconds (0d 0h 11m 2s)

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

Current thread (0x00007f87a2002800):  JavaThread "C2 CompilerThread2" daemon [_thread_in_vm, id=29699, stack(0x0000000126e57000,0x0000000126f57000)]


Current CompileTask:
C2: 662785 15152       4       sun.util.calendar.AbstractCalendar::getTime (174 bytes)

Stack: [0x0000000126e57000,0x0000000126f57000],  sp=0x0000000126f54fe0,  free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x2d2f42]
V  [libjvm.dylib+0x56509a]
V  [libjvm.dylib+0x5624aa]
V  [libjvm.dylib+0x56010b]
V  [libjvm.dylib+0x55f569]
V  [libjvm.dylib+0x1bd5e0]
V  [libjvm.dylib+0x21e459]
V  [libjvm.dylib+0x220355]
V  [libjvm.dylib+0x1a4350]
V  [libjvm.dylib+0x229ea5]
V  [libjvm.dylib+0x22965e]
V  [libjvm.dylib+0x67103c]
V  [libjvm.dylib+0x578ed2]
C  [libsystem_pthread.dylib+0x1899]  _pthread_body+0x8a
C  [libsystem_pthread.dylib+0x172a]  _pthread_struct_init+0x0
C  [libsystem_pthread.dylib+0x5fc9]  thread_start+0xd
C  0x0000000000000000


siginfo: si_signo: 11 (SIGSEGV), si_code: 0 (unknown), si_addr: 0x0000000000000000

Register to memory mapping:

RAX=0x00007f87a2fd0800 is an unknown value
RBX=0x0000000126f55118 is pointing into the stack for thread: 0x00007f87a2002800
RCX=0x00000001186f7e14 is at entry_point+22548 in (nmethod*)0x00000001186f2190
RDX=0x0000000000000000 is an unknown value
RSP=0x0000000126f54fe0 is pointing into the stack for thread: 0x00007f87a2002800
RBP=0x0000000126f54fe0 is pointing into the stack for thread: 0x00007f87a2002800
RSI=0x000005df88948e58 is an unknown value
RDI=0x00007f87a1804400 is an unknown value
R8 =0x0000000100000000 is an unknown value
R9 =0x0000000000000000 is an unknown value
R10=0x0000000000c19e99 is an unknown value
R11=0xffff807974b34988 is an unknown value
R12=0x000000010c395410: _ZTV14oop_Relocation+0x10 in /scratch/jenkins/workspace/9-dev-tier1-mac/build/jdk/lib/server/libjvm.dylib at 0x000000010bb6f000
R13=0x00000001186f2190 is at entry_point+-1136 in (nmethod*)0x00000001186f2190
R14=0x0000000126f55118 is pointing into the stack for thread: 0x00007f87a2002800
R15=0x5df88948e5894855 is an unknown value



Also part of replay log 
JvmtiExport can_access_local_variables 0
JvmtiExport can_hotswap_or_post_breakpoint 0
JvmtiExport can_post_on_exceptions 0
# 243 ciObject found
ciMethod java/lang/Object <init> ()V 4097 1 18798044 0 0
ciMethodData java/lang/Object <init> ()V 2 18798048 orig 288 128 26 57 12 1 0 0 0 40 197 199 37 1 0 0 0 56 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 77 68 79 32 101 120 116 114 97 32 100 97 116 97 32 108 111 99 107 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 1 159 246 8 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 248 3 0 0 248 31 0 0 2 0 0 0 0 0 3 0 1 0 0 0 0 0 0 0 0 0 0 0 254 255 255 255 0 0 0 0 0 0 0 0 data 4 0x0 0x9 0x1 0x0 oops 0 methods 0
ciMethod java/lang/IllegalArgumentException <init> ()V 1 1 264 0 -1
ciMethod sun/util/calendar/CalendarSystem forName (Ljava/lang/String;)Lsun/util/calendar/CalendarSystem; 9 1 2 0 -1
ciMethod sun/util/calendar/CalendarSystem newCalendarDate (Ljava/util/TimeZone;)Lsun/util/calendar/CalendarDate; 0 0 1 0 -1
ciMethod sun/util/calendar/Gregorian getCalendarDate (JLsun/util/calendar/CalendarDate;)Lsun/util/calendar/Gregorian$Date; 8817 1 25089 0 0
ciMethod sun/util/calendar/Gregorian newCalendarDate (Ljava/util/TimeZone;)Lsun/util/calendar/Gregorian$Date; 2049 1 64228 0 0
ciMethod sun/util/calendar/Gregorian getCalendarDate (JLsun/util/calendar/CalendarDate;)Lsun/util/calendar/CalendarDate; 2482657 1 42027 0 0
ciMethod sun/util/calendar/Gregorian newCalendarDate (Ljava/util/TimeZone;)Lsun/util/calendar/CalendarDate; 4097 1 38788 0 352
ciMethod sun/util/calendar/BaseCalendar normalizeMonth (Lsun/util/calendar/CalendarDate;)V 4097 1 27066 0 224
ciMethod sun/util/calendar/BaseCalendar getMonthLength (Lsun/util/calendar/CalendarDate;)I 28921 1 970 0 -1
ciMethod sun/util/calendar/BaseCalendar getDayOfYear (III)J 1265 1 14481 0 -1
ciMethod sun/util/calendar/BaseCalendar getFixedDate (Lsun/util/calendar/CalendarDate;)J 2945193 1 28735 0 0
ciMethod sun/util/calendar/BaseCalendar getFixedDate (IIILsun/util/calendar/BaseCalendar$Date;)J 16601 1 98446 0 0
ciMethod sun/util/calendar/BaseCalendar getCalendarDateFromFixedDate (Lsun/util/calendar/CalendarDate;J)V 2049 1 72651 0 0
ciMethod sun/util/calendar/BaseCalendar getDayOfWeekFromFixedDate (J)I 2049 1 75968 0 -1
ciMethod sun/util/calendar/BaseCalendar getGregorianYearFromFixedDate (J)I 1761 1 61115 0 -1
ciMethod sun/util/calendar/BaseCalendar isLeapYear (Lsun/util/calendar/CalendarDate;)Z 3379737 1 67212 0 0
ciMethod sun/util/calendar/BaseCalendar isLeapYear (I)Z 2049 1 8890 0 128
ciMethod sun/util/calendar/AbstractCalendar getCalendarDate (JLsun/util/calendar/CalendarDate;)Lsun/util/calendar/CalendarDate; 3378593 65 64794 0 0
ciMethod sun/util/calendar/AbstractCalendar getTime (Lsun/util/calendar/CalendarDate;)J 4097 1 25746 0 -1
ciMethod sun/util/calendar/AbstractCalendar getTimeOfDay (Lsun/util/calendar/CalendarDate;)J 3113 1 26255 0 0
ciMethod sun/util/calendar/AbstractCalendar getTimeOfDayValue (Lsun/util/calendar/CalendarDate;)J 2737 1 25954 0 0
ciMethod sun/util/calendar/AbstractCalendar setTimeOfDay (Lsun/util/calendar/CalendarDate;I)Lsun/util/calendar/CalendarDate; 3379737 1 66796 0 0
ciMethod sun/util/calendar/AbstractCalendar isLeapYear (Lsun/util/calendar/CalendarDate;)Z 0 0 1 0 -1
ciMethod sun/util/calendar/AbstractCalendar getNthDayOfWeek (IILsun/util/calendar/CalendarDate;)Lsun/util/calendar/CalendarDate; 833433 1 2841 0 -1
ciMethod sun/util/calendar/AbstractCalendar getFixedDate (Lsun/util/calendar/CalendarDate;)J 0 0 1 0 -1
ciMethod sun/util/calendar/AbstractCalendar getCalendarDateFromFixedDate (Lsun/util/calendar/CalendarDate;J)V 0 0 1 0 -1
Comments
Closing as duplicate of JDK-8150804.
15-03-2016
Sounds like this could be related to JDK-8150804 where we end up with a incorrect oop for a monitor object. I will push the following fix soon: http://cr.openjdk.java.net/~thartmann/8150804/webrev.02/ This should hit an assert in debug VMs. Does the issue only show up with product builds? Are you able to reproduce this to check if above fix solves the issue?
15-03-2016
We crash because of a bad oop when setting up a new nmethod. This is likely a compiler bug and not a GC bug.
15-03-2016
Looks like JDK-8150135.
25-02-2016
top of call stack: __ZN15G1CollectedHeap14is_scavengableEPKv __ZN18DetectScavengeRoot6do_oopEPP7oopDesc __ZN7nmethod7oops_doEP10OopClosureb __ZN7nmethodC2EP6MethodiiiP11CodeOffsetsiP24DebugInformationRecorderP12DependenciesP10CodeBufferiP9OopMapSetP21ExceptionHandlerTableP22ImplicitExceptionTableP16AbstractCompileri6HandleSI_ __ZN7nmethod11new_nmethodERK12methodHandleiiP11CodeOffsetsiP24DebugInformationRecorderP12DependenciesP10CodeBufferiP9OopMapSetP21ExceptionHandlerTableP22ImplicitExceptionTableP16AbstractCompileri6HandleSJ_ __ZN5ciEnv15register_methodEP8ciMethodiP11CodeOffsetsiP10CodeBufferiP9OopMapSetP21ExceptionHandlerTableP22ImplicitExceptionTableP16AbstractCompilerbb8RTMState __ZN7CompileC2EP5ciEnvP10C2CompilerP8ciMethodibbbP12DirectiveSet __ZN7CompileC1EP5ciEnvP10C2CompilerP8ciMethodibbbP12DirectiveSet
25-02-2016
[~roland], could you have a look?
25-02-2016
The symptom isn't reproducible. I'd like the hotspot team to evaluate this bug.
22-02-2016