JDK-8040254 : Garbage Collection on MacOSX can crash in fastdebug because of 'negative time'
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: os_x
  • CPU: x86
  • Submitted: 2014-04-15
  • Updated: 2014-04-22
  • Resolved: 2014-04-22
Related Reports
Duplicate :  
Relates :  
The test nsk/monitoring/stress/lowmem/lowmem025 crashed the VM on MacOSX in PIT JDK9_b08 with this error message:

# A fatal error has been detected by the Java Runtime Environment:
#  Internal Error (/opt/jprt/T/P1/184215.amurillo/s/hotspot/src/closed/share/vm/utilities/ticks.cpp:28), pid=57995, tid=10243
#  assert(end >= start) failed: negative time!
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-201404111842.amurillo.jdk9-hs-2014-04-11-b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b62-fastdebug mixed mode bsd-amd64 compressed oops)
# 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

Priority justification:
Impact: High: Crash
Likelihood: Low: Has only happened once (yet)
Workaround: High: No workaround known

ILW = HLH => P2

RULE nsk/monitoring/stress/lowmem/lowmem025 Crash Internal Error ...ticks.cpp...assert(end >= start) failed: negative time!
Probably a duplicate of JDK-8040140?

The Ticks::value being compared in the assert appears to come from os::elapsed_counter