JDK-8222823 : [Graal] assert Universe::heap()->is_in(o)) failed: should be in closed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 13
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2019-04-22
  • Updated: 2019-07-10
  • Resolved: 2019-07-10
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 13
13Resolved
Related Reports
Relates :  
JDK-8225064 - [Graal] Application SEGV in G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markOopDesc*)+0x48
Description
#  Internal Error (open/src/hotspot/share/memory/iterator.inline.hpp:60), pid=20432, tid=20494
#  assert(Universe::heap()->is_in(o)) failed: should be in closed *p 0x0000000743869760 0x00000005d56dd5f0

One crash in compiler/codegen/TestTrichotomyExpressions.java so far.
Comments
Closing as Cannot Reproduce.
10-07-2019
There are no recent failures. I would suggest to closed and re-open it if see the failure again. Most likely it is fixed by recent Graa./JVMCI changes as Rahul said.
09-07-2019
I attached it. I downloaded test run data from artifactory.
07-06-2019
How can I see the hs_err_pid42748.log mentioned in the log [~epavlova]?
07-06-2019
Reopened. Probably a dup of JDK-8223794.
04-06-2019
[~dlong], should not we reopen the issue as it is still seen ?
04-06-2019
I still see this issue, it happened on windows: Internal Error (t:\\workspace\\open\\src\\hotspot\\share\\memory/iterator.inline.hpp:61), pid=42748, tid=9796 [stress.process.out] # assert(Universe::heap()->is_in(o)) failed: should be in closed *p 0x000000043bea511c 0x000000044738b080 [stress.process.out] # [stress.process.out] # JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-internal+0-2019-06-04-0444198.ekaterina.pavlova.jdk.jdk) [stress.process.out] # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-2019-06-04-0444198.ekaterina.pavlova.jdk.jdk, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, g1 gc, windows-amd64)
04-06-2019
Most likely fixed by JDK-8222665. Please re-open if not.
13-05-2019
Looks like this issue should be resolved by JDK-8222665.
29-04-2019
I don't think we have anything else outstanding that we know of though G1 isn't our primary test target so we see problems there less often. That hs_err log indicates there's some problem with the active compilation dumping in fastdebug mode. Threads with active compile tasks: JVMCI CompilerThread0 [error occurred during error reporting (printing all threads), id 0xe0000000, Internal Error (open/src/hotspot/share/runtime/timer.cpp:112)] From that message it looks like the timestamp on the outputStream hasn't been updated though it appears VMError explicitly initializes them so I'm not sure what's going wrong when it calls CompileTask::print_on.
26-04-2019
Based on list of fixes in last 'Update Graal' JDK-8221598 it does not have GR-12682 changes. And I verified that current Graal code in JDK does not have these changes.
26-04-2019
Isn't this most likely to be the problem with register kills in the zeroing code? It's a generic bug but mostly manifested with G1 as a bad oop. The fix is 25e5539e185 04.23.19 12:03 Tom Rodriguez [GR-15362] Correct register kills for AMD64ZeroMemoryOp. and the bug was introduced by ec7963212c4 04.17.19 17:45 Yudi Zheng [GR-12682] Use bulk zeroing when instantiating large arrays. Does JDK13 have the last one?
26-04-2019
There are a number of G1 related fixes we've made recently: GR-15362, GR-15272 Are there others [~never] that might be related?
26-04-2019
Doug, you've mentioned on github that issue 1159 should be fixed by: https://github.com/graalvm/graal-jvmci-8/commit/a53131efce4e1c7d4e5aa3eefef504fee750e9f3 But since that method does not exist in JDK 13 jvmci, I expect that this is another failures, right?
26-04-2019
The 0xbaadbabe values also show up in the "from" array, at the same relative positions. Perhaps Graal offered a safepoint before fully initializing the array?
25-04-2019
Just fyi, there is a recent open issue with Graal that strongly indicates some naked oop (or similar) in the compiler: https://github.com/oracle/graal/issues/1159: - crashes in the "before GC verification" - there seems to be no reason for such errors to be OSX specific Note that I am not sure whether the version of Graal used here corresponds to the one in the bug report, but there has been a big Graal update recently.
24-04-2019
0x00000005d56dd5f0 is 0xbaadbabe decoded as a narrowoop. (gdb) x/20x 0x0000000743869760-20 0x74386974c: 0xe871e302 0xe8740162 0xe8740162 0xe8740162 0x74386975c: 0xe8740162 0xbaadbabe 0xbaadbabe 0xbaadbabe 0x74386976c: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe 0x74386977c: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe 0x74386978c: 0xbaadbabe 0xbaadbabe 0xbaadbabe 0xbaadbabe
24-04-2019