JDK-8227411 : TestTimeMultiple.java failed "assert(!lease()) failed: invariant"
  • Type:Bug
  • Component:hotspot
  • Sub-Component:jfr
  • Affected Version:11,12,13
  • Priority:P3
  • Status:Resolved
  • Resolution:Fixed
  • CPU:x86_64
  • Submitted:2019-07-08
  • Updated:2020-06-01
  • Resolved:2019-09-02
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 11JDK 13JDK 14
11.0.6Fixed 13.0.4Fixed 14 b13Fixed
Description
The following test failed in the JDK13 CI: jdk/jfr/api/recording/time/TestTimeMultiple.java Here's a snippet from the log file: #section:main ----------messages:(5/277)---------- command: main jdk.jfr.api.recording.time.TestTimeMultiple reason: User specified action: run main/othervm jdk.jfr.api.recording.time.TestTimeMultiple Mode: othervm [/othervm specified] Additional options from @modules: --add-modules jdk.jfr elapsed time (seconds): 11.81 ----------configuration:(3/38)---------- Boot Layer add modules: jdk.jfr ----------System.out:(18/1055)*---------- # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=t:/workspace/open/src/hotspot/share/jfr/recorder/storage/jfrBuffer.cpp:58 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (t:/workspace/open/src/hotspot/share/jfr/recorder/storage/jfrBuffer.cpp:58), pid=9396, tid=10776 # assert(!lease()) failed: invariant # # JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-ea+0-1429) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-ea+0-1429, mixed mode, sharing, tiered, compressed oops, g1 gc, windows-amd64) # Core dump will be written. Default location: T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_jfr\\scratch\\5\\hs_err_pid9396.mdmp # # An error report file with more information is saved as: # T:\\testoutput\\test-support\\jtreg_open_test_jdk_jdk_jfr\\scratch\\5\\hs_err_pid9396.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # ----------System.err:(0/0)---------- ----------rerun:(40/4860)*----------
Comments
Fix request (13u): The original patch applies cleanly, tested with jdk/jfr tests.
26-05-2020
I'll sponsor this backport after running it through regression tests.
01-10-2019
Fix Request This patch applies cleanly to 11u.
19-09-2019
URL: https://hg.openjdk.java.net/jdk/jdk/rev/ca9e3b68a969 User: mgronlun Date: 2019-09-02 13:05:46 +0000
02-09-2019
Writing the mspaces for the checkpoint subsystem is currently premised on exclusive access to the respective mspaces at the point of writing. This is true for the regular "free list" mspace, because the write happens after a safepoint. The safepoint will shift the epoch and install the "epoch transition mspace" which is in place until the free list mspace is written and reinstalled as part of post_safepoint_write(). Data eventually added to the epoch transition mspace is logically part of the next epoch, and it will be written in the next, upcoming rotation, as part of pre_safepoint_write(). There is a rare race here though: Writing the epoch transition mspace during pre_safepoint_write() is currently _not_ exclusive, because there is no safepoint between post_safepoint_write() and pre_safepoint_write(). The window where the epoch transition mspace is accesible is very narrow (between safepoint_write() and post_safepoint_write()), but there exist a case where a thread could fetch a buffer from this mspace, just before the epochs are synched up in post_safepoint_write(). If the next chunk rotation happens instantly after coming out of post_safepoint_write(), it directly enters pre_safepoint_write() for writing the epoch transition mspace. The thread that fetched the buffer could still be writing to that mspace at this point. This is a very rare race, usually rotations happen relatively seldom. The probability for entering this race is increased for test code because a "stop" message usually come directly after the chunk rotation (requesting shutdown). Writers accessing the epoch transition mspace as part of pre_safepoint_write() must therefore first ensure exclusive access to the buffer (by acquiring it) before attempting the write and reinitialization.
13-08-2019
ILW = HLM = P3
11-07-2019


close