The G1HeapRegion gtest in gc/g1/test_heapRegion.cpp fails with the following assertion:

# Internal Error (/home/kab/gitsb/gtest-atomic/jdk/open/src/hotspot/share/gc/shared/markBitMap.cpp:63), pid=1755598, tid=1755606
# assert(Universe::heap()->is_in(addr)) failed: Trying to access bitmap 0x0000aaab0f780370 for address 0x0000000425800000 not in the heap.

This only happens if gtests are run directly, e.g.
make test TEST=gtest
The test passes if one insted uses the jtreg GTestWrapper.java to run them, e.g.
make test TEST=hotspot/gtest/GTestWrapper.java
which is why we're not seeing failures in mach5 or other CIs.

The two methods invoke the gtestLauncher with *almost* the same command line. The difference is that the GTestWrapper adds a -Xmx200m option, while the direct method doesn't. That argument was added to the GTestWrapper by JDK-8320836 to limit the heap size when running gtests. Without it, the heap size on my dev machine is much larger.

The value of InitialHeapSize seems to be the same for both invocation methods. However, the values of G1HeapRegionSize differ. For direct invocation, on my dev machine, G1HeapRegionSize == InitialHeapSize. When using the GTestWrapper, the limited -Xmx value also reduces the value of HeapRegionSize. As a result, direct invocation starts with one region, while the GTestWrapper starts with several.

The test creates a G1CMBitMap for the first region, and marks some bitmap entries corresponding to some addresses in that region. It also attempts to mark the entry corresponding to the end of the region. And that fails if there is only one region, since that's not inside the (current) heap.

This seems to be the result of a somewhat recent change. The test hasn't changed in any relevant way, and I normally use direct invocation to run the gtests when I want to run just them. Though it may have been a while since I ran all of them, rather than a selected subset that didn't include the G1HeapRegion test.