GC crashed with an assertion failure in Scavenger.cpp #17052

connglli · 2023-03-29T05:37:00Z

Java version

openjdk version "11.0.19-internal" 2023-04-18
OpenJDK Runtime Environment (build 11.0.19-internal+0-adhoc..openj9-openjdk-jdk11)
Eclipse OpenJ9 VM (build master-f14707f, JRE 11 Linux amd64-64-Bit Compressed References 20230303_000000 (JIT enabled, AOT enabled)
OpenJ9   - f14707f
OMR      - 342b647
JCL      - a8cc681 based on jdk-11.0.19+4)

Javac version

javac 11.0.19-internal

Code and summary of the problem

Code and logs: see issue17052.tar.gz. The code Test.java is a bit long because I ain't able to reduce it.

This seems to be the most reproducible problem out of the 12 as mentioned in our previous chat. I can reproduce exactly the same assertion failure (Scavenger.cpp:1669) 3 times out of 4 runs. I put logs of all these 4 runs in the link above, each in a directory named log.XXXXX. Hope the same frequency applies to you too. It makes OpenJ9 to crash in GC and should be a JIT bug since there aren't any crash if -Xint is enabled.

The test exited with code 255 and the assertion log (log.bOTRV, log.D1Uma, log.RtuV0) looks like

Corruption in Evacuate at 00000000FFD00048: calculated object size 140448003833796 larger than available 1572792, Forwarded Header at 00007FBC752B7300
21:12:28.372 0x25a500    j9mm.141    *   ** ASSERTION FAILED ** at /root/hostdir/openj9-openjdk-jdk11/omr/gc/base/standard/Scavenger.cpp:1669: ((false))
JVMDUMP039I Processing dump event "traceassert", detail "" at 2023/03/15 21:12:28 - please wait.
JVMDUMP032I JVM requested System dump using '/home/cli/ax-exp/openj9/Artemis/core.20230315.211228.900368.0001.dmp' in response to an event
JVMPORT030W /proc/sys/kernel/core_pattern setting "|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" specifies that the core dump is to be piped to an external program.  Attempting to rename either core or core.900864.  Review the manual for the external program to find where the core dump is written and ensure the program does not truncate it.

JVMPORT049I The core file created by child process with pid = 900864 was not found. Review the documentation for the /proc/sys/kernel/core_pattern program "|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" to find where the core file is written and ensure that program does not truncate it.

JVMDUMP012E Error in System dump: /home/cli/ax-exp/openj9/Artemis/core.20230315.211228.900368.0001.dmp
JVMDUMP032I JVM requested Java dump using '/home/cli/ax-exp/openj9/Artemis/javacore.20230315.211228.900368.0002.txt' in response to an event
JVMDUMP010I Java dump written to /home/cli/ax-exp/openj9/Artemis/javacore.20230315.211228.900368.0002.txt
JVMDUMP032I JVM requested Snap dump using '/home/cli/ax-exp/openj9/Artemis/Snap.20230315.211228.900368.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /home/cli/ax-exp/openj9/Artemis/Snap.20230315.211228.900368.0003.trc
JVMDUMP013I Processed dump event "traceassert", detail "".

The last run (log.d3ZAp) crashed with a different assertion failure:

07:29:17.836 0x1aa00    j9mm.107    *   ** ASSERTION FAILED ** at /root/hostdir/openj9-openjdk-jdk11/omr/gc/base/MemoryPoolAddressOrderedList.cpp:1428: ((false && ((__null == nextFreeEntry) || (addrTop <= nextFreeEntry))))
JVMDUMP039I Processing dump event "traceassert", detail "" at 2023/03/28 15:29:17 - please wait.
JVMDUMP032I JVM requested System dump using '/home/simon/Desktop/test-jitcomp/ax-eval/bugs2/12.openj9/mutant/red/core.20230328.152917.2166141.0001.dmp' in response to an event
JVMPORT030W /proc/sys/kernel/core_pattern setting "|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" specifies that the core dump is to be piped to an external program.  Attempting to rename either core or core.2166212.  Review the manual for the external program to find where the core dump is written and ensure the program does not truncate it.

JVMPORT049I The core file created by child process with pid = 2166212 was not found. Review the documentation for the /proc/sys/kernel/core_pattern program "|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" to find where the core file is written and ensure that program does not truncate it.

JVMDUMP012E Error in System dump: /home/simon/Desktop/test-jitcomp/ax-eval/bugs2/12.openj9/mutant/red/core.20230328.152917.2166141.0001.dmp
JVMDUMP032I JVM requested Java dump using '/home/simon/Desktop/test-jitcomp/ax-eval/bugs2/12.openj9/mutant/red/javacore.20230328.152917.2166141.0002.txt' in response to an event
JVMDUMP010I Java dump written to /home/simon/Desktop/test-jitcomp/ax-eval/bugs2/12.openj9/mutant/red/javacore.20230328.152917.2166141.0002.txt
JVMDUMP032I JVM requested Snap dump using '/home/simon/Desktop/test-jitcomp/ax-eval/bugs2/12.openj9/mutant/red/Snap.20230328.152917.2166141.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /home/simon/Desktop/test-jitcomp/ax-eval/bugs2/12.openj9/mutant/red/Snap.20230328.152917.2166141.0003.trc
JVMDUMP013I Processed dump event "traceassert", detail "".

The text was updated successfully, but these errors were encountered:

connglli · 2023-03-29T06:00:47Z

For the rest 11, see issue17052rest11.tar.gz

For convenience, I summarize them in the following table. I hope this can help you, simplifying your work (I know it's somewhat a headache, so I'm sorry). I put each test per directory named X.openj9, each following the same directory structure as the main issue mentioned above. In the table, the key perhaps_unique is the unique symptom (if it is) that I wanted to display to you. But as you may noticed, for some of them, I'm not able to reproduce for a second time. The key log.XXXXX is a summary of the failure I have encountered when trying to reproduce the corresponding test.

In addition, besides the (perhaps) unique symptom, there're chances that different tests can lead to the same crash symptom because of their non-determinism (and some tests can even trigger crashes that I've reported before like #15476). This indicate they are maybe, not unique?

3.openj9
- perhaps_unique: assertion failed ScavengerDelegate.cpp:469: ((false))
- log.1B22R: assertion failed ScavengerDelegate.cpp:469: ((false))
- log.DZo00: assertion failed Scavenger.cpp:1669: ((false))
- log.xhKX6: segmentation error ZN12MM_Scavenger14copyForVariantILb0EEEP8J9ObjectP22MM_EnvironmentStandardP18MM_ForwardedHeader+0x77e

5.openj9 
- perhaps_unique: assertion failed ScavengerRootScanner.hpp:105: ((MM_StackSlotValidator(MM_StackSlotValidator::COULD_BE_FORWARDED, *slotPtr, stackLocation, walkState).validate(_env)))
- log.vfCGQ: assertion failed ScavengerRootScanner.hpp:105: ((MM_StackSlotValidator(MM_StackSlotValidator::COULD_BE_FORWARDED, *slotPtr, stackLocation, walkState).validate(_env)))
- log.3u8ai: assertion failed ScavengerRootScanner.hpp:109: ((MM_StackSlotValidator(MM_StackSlotValidator::NOT_ON_HEAP, *slotPtr, stackLocation, walkState).validate(_env)))
- log.QDWaj: assertion failed ScavengerRootScanner.hpp:109: ((MM_StackSlotValidator(MM_StackSlotValidator::NOT_ON_HEAP, *slotPtr, stackLocation, walkState).validate(_env)))

6.openj9
- perhaps_unique: assertion failed Scavenger.cpp:1634: ((false))
- log.ES0IO: assertion failed Scavenger.cpp:1669: ((false))
- log.DHfO3: segmentation error _ZN18MM_ForwardedHeader17copyOrWaitOutlineEP8J9Object+0x30
- log.eJxJG: assertion failed ScavengerDelegate.cpp:469: ((false))

7.openj9
- perhaps_unique: segmentation error old_fast_jitLookupInterfaceMethod+0x4d
- log.wER9m: segmentation error old_fast_jitLookupInterfaceMethod+0x4d
- log.g4c0e: assertion failed ScavengerDelegate.cpp:469: ((false))
- log.AYVgj: assertion failed Scavenger.cpp:2731: ((false))

8.openj9
- perhaps_unique: assertion failed SweepPoolManagerAddressOrderedListBase.cpp:481: ((false && (objectSizeDelta <= heapFreeByteCount)))
- log.jYkx3: assertion failed SweepPoolManagerAddressOrderedListBase.cpp:481: ((false && (objectSizeDelta <= heapFreeByteCount)))
- log.26AEM: assertion failed SweepPoolManagerAddressOrderedListBase.cpp:481: ((false && (objectSizeDelta <= heapFreeByteCount)))
- log.PFDIo: segme error _ZN22GC_ObjectModelDelegate29calculateObjectDetailsForCopyEP18MM_EnvironmentBaseP18MM_ForwardedHeaderPmS4_S4_+0x34

9.openj9
- perhaps_unique: segmentation error _ZN23MM_TLHAllocationSupport7refreshEP18MM_EnvironmentBaseP22MM_AllocateDescriptionb+0x338 
- log.0gxUk: segmentation error _ZN23MM_TLHAllocationSupport7refreshEP18MM_EnvironmentBaseP22MM_AllocateDescriptionb+0x338 
- log.4f6XI: segmentation error _ZN22GC_ObjectModelDelegate29calculateObjectDetailsForCopyEP18MM_EnvironmentBaseP18MM_ForwardedHeaderPmS4_S4_+0x34
- log.nBVOa: segmentation error _ZN22GC_ObjectModelDelegate29calculateObjectDetailsForCopyEP18MM_EnvironmentBaseP18MM_ForwardedHeaderPmS4_S4_+0x34

11.openj9
- perhaps_unique: segmentation error findFieldInClass+0x99
- log.R1thu: assertion failed ScavengerRootScanner.hpp:109: ((MM_StackSlotValidator(MM_StackSlotValidator::NOT_ON_HEAP, *slotPtr, stackLocation, walkState).validate(_env)))
- log.COHB9: segmentation error _ZN23MM_ScavengerRootClearer26scavengeUnfinalizedObjectsEP22MM_EnvironmentStandard+0x300
- log.E7Gfs: assertion failed ScavengerRootClearer.cpp:198: ((false && (__null != forwardedPtr)))

13.openj9
- perhaps_unique: segmentation error haltThreadForInspection+0xa3 
- log.nUWNA: segmentation error _ZN31MM_MemoryPoolAddressOrderedList11allocateTLHEP18MM_EnvironmentBaseP22MM_AllocateDescriptionmRPvS5_+0x7f
- log.cfpHi segmentation error protectedBacktrace+0x12
- log.QUpX3 segmentation error protectedBacktrace+0x12

14.openj9
- perhaps_unique: assertion failed MemorySubSpace.cpp:185: ((false && (reason <= LOA_EXPAND_LAST_RESIZE_REASON)))
- log.9CGLb: assertion failed MemorySubSpace.cpp:185: ((false && (reason <= LOA_EXPAND_LAST_RESIZE_REASON)))

15.openj9
- perhaps_unique: assertion failed Scavenger.cpp:2731: ((false))
- log.cYvMU: assertion failed Scavenger.cpp:2731: ((false))
- log.TJ8np: assertion failed Scavenger.cpp:2731: ((false))
- log.3FZkI: assertion failed ConcurrentMarkingDelegate.cpp:58: ((MM_StackSlotValidator(0, object, stackLocation, walkState).validate(data->env)))
- log.khhfj: segmentation error romFieldSize+0xc3
- log.tD88r: assertion failed ScavengerDelegate.cpp:469: ((false))

16.openj9
- perhaps_unique: assertion failed MarkingSchemeRootMarker.cpp:48: ((MM_StackSlotValidator(0, object, stackLocation, walkState).validate(_env)))
- log.0xAEW: assertion failed Scavenger.cpp:1669: ((false))
- log.N97lH: segmentation error _ZN22GC_ObjectModelDelegate29calculateObjectDetailsForCopyEP18MM_EnvironmentBaseP18MM_ForwardedHeaderPmS4_S4_+0x34 
- log.vqj3w: segmentation error _ZN12MM_Scavenger16rescanThreadSlotEP22MM_EnvironmentStandardPP8J9Object+0xea 
- log.yTdHX: segmentation error _ZN18MM_ForwardedHeader17copyOrWaitOutlineEP8J9Object+0x30

pshipton · 2023-03-29T11:58:17Z

@0xdaryl @hzongaro

dmitripivkine · 2023-03-29T13:25:03Z

Most of these assertions in GC might be triggered by heap corruption. There are a very few of them I need to double check, the connection with possible heap corruption is not obvious.

dmitripivkine · 2023-03-29T17:14:07Z

I walked this list of assertions/crashes in GC. There is only one of them can not be explained by heap corruption directly:

MemorySubSpace.cpp:185: ((false && (reason <= LOA_EXPAND_LAST_RESIZE_REASON))) this assertion means heap expansion is requested but heap contraction has been performed previous GC. It might be side effect of bad allocation request (to large object?) potentially. We observed this error in the past but can not reproduce. The heuristics responsible for expand/contract logic have been reviewed and adjusted but we did not have a chance to verify correctness.

If somebody needs triaging of failures in GC listed above please let me know, I will help with this. Of course, system core is necessary.

connglli · 2023-03-29T17:20:56Z

Oops. That happens to be the test I was unable to reproduce (and my procedure deleted the log periodically)..... Still hope that test could be helpful, to some extend. I'll try again to see if I can reproduce it in more runs.

connglli · 2023-03-30T07:05:13Z

I have reproduced the failure mentioned by @dmitripivkine. See logs: issue17052rest11.14.tar.gz.

I edited and also updated the issue17052rest11.tar.gz in my previous comment.

dmitripivkine · 2023-06-20T15:14:50Z

The problem starts at attempt to allocate object with 1836453136 bytes size. With -Xmx1G specified it is not possible obviously:

14:52:37.237385000                *0x0       j9mm.133  Event       Allocation failure start: newspace=8080/2097152 oldspace=5649544/6291456 loa=0/0 requestedbytes=1836453136

@connglli Do you know is allocation of this array of such size is intentional for this test load?

dmitripivkine · 2023-06-20T16:06:22Z

@connglli The rational for question above:

If allocation of the object size larger than heap is intentional the only problem is GC should not assert but throw OOM.
However is allocation of so large object is not intentional there is another problem in JVM somewhere failed to calculate required object size properly. If it is the case we should look to this problem at the first place

connglli · 2023-06-20T16:40:21Z

@dmitripivkine The code is generated by our fuzzers. In our fuzzer implementation, we have restricted the size of any array allocation. I have checked the code again, and didn't notice any explicit array allocation of which the size is larger than 524,288(=256x256x8) bytes. But we did generate some library method calls like those of Double, Float, BigDecimal, BigInteger, etc. I suppose they don't have some implicit large array allocations, either (even though I'm not quite sure).

connglli · 2023-06-20T16:43:59Z

Could you please check the stack trace such that we can get some glue on which array allocation caused this assertion failure? By the way, I'm sorry I'm on my vacation so I might not be that on call.

dmitripivkine · 2023-06-20T16:54:21Z

Could you please check the stack trace such that we can get some glue on which array allocation caused this assertion failure? By the way, I'm sorry I'm on my vacation so I might not be that on call.

3XMTHREADINFO3           Java callstack:
4XESTACKTRACE                at java/nio/HeapByteBuffer.<init>(HeapByteBuffer.java:61)
4XESTACKTRACE                at java/nio/ByteBuffer.allocate(ByteBuffer.java:348)
4XESTACKTRACE                at Test.mainTest(Test.java:600(Compiled Code))
4XESTACKTRACE                at Test.main(Test.java:726)

connglli · 2023-06-20T17:08:44Z

Oh sure yes, it is a library call ax$45.write(ByteBuffer.allocate(i22)). So for this test an OOM should be thrown instead of an assertion failure. I forgot to check the size of the argument i22 in my fuzzer implementation. But seems that it is a good design to abandon all size checks so that we can find some corner-cases like this :-).

How about the others, I didn't notice ByteBuffer.allocate() in the test like the main comment.

dmitripivkine · 2023-06-20T18:18:55Z

An assertion in MemorySubSpace.cpp:185 is an obvious problem in GC code (and as a GC Team member I have a priority). The rest of listed assertions are triggered by external to GC reasons (bad O-slot in java stack or heap corruption). I can triage such assertion/crash problems and assign to right component (JIT most likely) but I need system dump to look at. And I don't see any at the moment. Do you have any system dumps left around?

hzongaro · 2023-07-10T13:48:50Z

I was able to reproduce this failure with this option:

-Xjit:limit={Test.fMeth*},optLevel=hot,lastOptIndex=84

but not with lastOptIndex=83. In this case, opt index 84 was Loop Versioner. The transformations listed for that method in Loop Versioner were

[  3719]  84.1    O^O LOOP VERSIONER: Versioning natural loop 326
[  3720]  84.2    O^O LOOP VERSIONER:  Creating test outside loop for deciding if async check is required
[  3721]  84.3    O^O LOOP VERSIONER:  Creating test outside loop for checking if n4045n [00007F7EA875E010] exceeds bounds

This bears some resemblance to the situation described in issue #17249, so it could be related. I'll assign it to myself for now, in case this is a duplicate.

hzongaro · 2023-08-14T21:52:34Z

I haven't been able to make progress on this one for 0.41. I will move it to the 0.43 release.

hzongaro · 2023-10-10T19:26:42Z

I think this is likely a duplicate of #17249, so I'll assign it to @a7ehuo.

a7ehuo · 2023-10-30T15:31:16Z

I can still reproduce the GC assert with the fix for #17249. This issue is also reproducible with disableAsyncCheckVersioning.

-Xjit:limit={Test.fMeth*},{*}(disableAsyncCheckVersioning,optLevel=hot,lastOptIndex=84,optDetails,traceFull,traceILGen,traceCG,traceLoopVersioner,log=logs/jitlog)' Test

Bad scan type for object pointer 00000000A3617EA8
14:37:34.934 0x1aa00    j9mm.141    *   ** ASSERTION FAILED ** at /root/home/ahuo/src/openj9-openjdk-jdk17/openj9/runtime/gc_glue_java/ScavengerDelegate.cpp:480: ((false))

The GC assert happens with lastOptSubIndex=2 but not lastOptSubIndex=1. This issue seems related to versioning bound check. Meanwhile neither _conditionalTree nor _duplicatedContionalTree is set, which is related to the root cause of #17249.

[  1974]  84.1    O^O LOOP VERSIONER: Versioning natural loop 14
versionNaturalLoop: DEBUG calling buildBoundCheckComparisonsTree. _conditionalTree 0000000000000000 n-1n _duplicatedContionalTree 0000000000000000 n-1n
[  1975]  84.2    O^O LOOP VERSIONER:  Creating test outside loop for checking if n824n [00007F723047F140] exceeds bounds

hzongaro · 2023-10-30T18:53:19Z

Thanks for checking into that, Annabelle @a7ehuo. Brad @BradleyWood, following that investigation I'm now wondering whether this might be a duplicate of issue #17045, which you've been investigating.

BradleyWood · 2023-10-31T15:14:45Z

Yes, I think its the same problem.

I see the same kind of snippet.

try {
    for (int ax$16 = 0; ax$16 <= 3; ax$16++) {
        for (int ax$17 = 0; ax$17 <= 3; ax$17++) {
            ax$15[ax$16 * ax$17] += 1;
        }
    }
} catch (Throwable ax$18) {
} finally {
}

I'm guessing the loop limit transformation is off by one. Does changing ax$17 <= 3 to ax$17 < 4 fix it?

a7ehuo · 2023-10-31T16:44:06Z

Does changing ax$17 <= 3 to ax$17 < 4 fix it?

Yes. The test passes with the change

                        for (int ax$16 = 0; ax$16 <= 3; ax$16++) {
                            for (int ax$17 = 0; ax$17 < 4; ax$17++) { // Pass
                                ax$15[ax$16 * ax$17] += 1;
                            }

hzongaro · 2023-10-31T18:51:38Z

I'll reassign this to Brad @BradleyWood, as it looks like this is likely a duplicate of #17045

a7ehuo · 2023-10-31T21:59:22Z

Just post what I have observed on the failure from this test. Hope it helps. Brad will continue the investigation.

I'm guessing the loop limit transformation is off by one

I noticed the difference between ax$17 <= 3 and ax$17 < 4 is adjustMaxValue, which is calculated from incrementJ based on isIndexChildMultiplied.

ax$17 <= 3 case:

incrementJ is 1; isIndexChildMultiplied is 1
maxValue = maxValue - adjustMaxValue = maxValue - (incrementJ+1) = 4 - (1+1) = 2

ax$17 < 4 case:

incrementJ is 1; isIndexChildMultiplied is 0
maxValue = maxValue - adjustMaxValue = maxValue - incrementJ = 4 - 1 = 3

isIndexChildMultiplied is different for these two cases from what I observed. It results in the final maxValue for ax$17 as 2 when ax$17 <= 3. I haven't got to trace why isIndexChildMultiplied is different.

a7ehuo · 2023-11-01T13:11:28Z

isIndexChildMultiplied is different for these two cases from what I observed. It results in the final maxValue for ax$17 as 2 when ax$17 <= 3.

Sorry I realized my previous logging is incorrect. It is the incrementJ that's different for these two cases.

ax$17 <= 3 case:

incrementJ is 1; isIndexChildMultiplied is 1
maxValue = maxValue - adjustMaxValue = maxValue - (incrementJ+1) = 4 - (1+1) = 2

ax$17 < 4 case:

incrementJ is 0; isIndexChildMultiplied is 1
maxValue = maxValue - adjustMaxValue = maxValue - (incrementJ+1) = 4 - (0+1) = 3

BradleyWood · 2023-11-01T14:14:19Z

Those values are determined by the type of compare operator. I guess the logic doesn't hold when the indices are product of two induction variables?

hzongaro · 2024-01-30T15:56:14Z

@BradleyWood, may I ask you to check whether this problem was fixed by either or both the OMR pull requests eclipse/omr#7237 and eclipse/omr#7238?

BradleyWood · 2024-01-30T16:14:21Z

@hzongaro Its fixed

pshipton added comp:jit userRaised labels Mar 29, 2023

pshipton added this to the Release 0.40? (Java 8, 11, 17, 20) July refresh milestone Mar 29, 2023

dmitripivkine mentioned this issue Mar 29, 2023

JDK11 Segmentation Error vmState=0x0002000f #17045

Closed

pshipton mentioned this issue Apr 21, 2023

SC_Softmx_JitAot_Linux Invalid class pointer assert MarkingSchemeRootMarker.cpp:48 #17240

Closed

0xdaryl modified the milestones: Release 0.40 (Java 8, 11, 17, 20) July refresh, Release 0.41 (Java 8, 11, 17) Oct refresh Jun 5, 2023

pshipton mentioned this issue Jun 15, 2023

MauveSingleThrdLoad_J9_5m Misaligned stack-allocated object #17601

Closed

pshipton mentioned this issue Jun 26, 2023

HCRLateAttachWorkload segfaults with -Xint #14292

Open

hzongaro self-assigned this Jul 10, 2023

hzongaro modified the milestones: Release 0.41 (Java 8, 11, 17) Oct refresh, Release 0.43 (Java 8, 11, 17, 21) Jan refresh Aug 14, 2023

hzongaro assigned a7ehuo and unassigned hzongaro Oct 10, 2023

hzongaro assigned BradleyWood and unassigned a7ehuo Oct 31, 2023

BradleyWood mentioned this issue Nov 9, 2023

Correct loop limit adjustment for bound check versioning eclipse/omr#7174

Closed

hzongaro modified the milestones: Release 0.43 (Java 8, 11, 17, 21) Jan refresh, Release 0.44 (Java 8, 11, 17, 21) Apr refresh Nov 13, 2023

BradleyWood closed this as completed Jan 30, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GC crashed with an assertion failure in Scavenger.cpp #17052

GC crashed with an assertion failure in Scavenger.cpp #17052

connglli commented Mar 29, 2023 •

edited

Loading

connglli commented Mar 29, 2023 •

edited

Loading

pshipton commented Mar 29, 2023

dmitripivkine commented Mar 29, 2023

dmitripivkine commented Mar 29, 2023

connglli commented Mar 29, 2023 •

edited

Loading

connglli commented Mar 30, 2023

dmitripivkine commented Jun 20, 2023

dmitripivkine commented Jun 20, 2023

connglli commented Jun 20, 2023

connglli commented Jun 20, 2023

dmitripivkine commented Jun 20, 2023

connglli commented Jun 20, 2023

dmitripivkine commented Jun 20, 2023

hzongaro commented Jul 10, 2023 •

edited

Loading

hzongaro commented Aug 14, 2023

hzongaro commented Oct 10, 2023

a7ehuo commented Oct 30, 2023

hzongaro commented Oct 30, 2023

BradleyWood commented Oct 31, 2023

a7ehuo commented Oct 31, 2023

hzongaro commented Oct 31, 2023

a7ehuo commented Oct 31, 2023

a7ehuo commented Nov 1, 2023

BradleyWood commented Nov 1, 2023

hzongaro commented Jan 30, 2024

BradleyWood commented Jan 30, 2024

GC crashed with an assertion failure in Scavenger.cpp #17052

GC crashed with an assertion failure in Scavenger.cpp #17052

Comments

connglli commented Mar 29, 2023 • edited Loading

Java version

Javac version

Code and summary of the problem

connglli commented Mar 29, 2023 • edited Loading

pshipton commented Mar 29, 2023

dmitripivkine commented Mar 29, 2023

dmitripivkine commented Mar 29, 2023

connglli commented Mar 29, 2023 • edited Loading

connglli commented Mar 30, 2023

dmitripivkine commented Jun 20, 2023

dmitripivkine commented Jun 20, 2023

connglli commented Jun 20, 2023

connglli commented Jun 20, 2023

dmitripivkine commented Jun 20, 2023

connglli commented Jun 20, 2023

dmitripivkine commented Jun 20, 2023

hzongaro commented Jul 10, 2023 • edited Loading

hzongaro commented Aug 14, 2023

hzongaro commented Oct 10, 2023

a7ehuo commented Oct 30, 2023

hzongaro commented Oct 30, 2023

BradleyWood commented Oct 31, 2023

a7ehuo commented Oct 31, 2023

hzongaro commented Oct 31, 2023

a7ehuo commented Oct 31, 2023

a7ehuo commented Nov 1, 2023

BradleyWood commented Nov 1, 2023

hzongaro commented Jan 30, 2024

BradleyWood commented Jan 30, 2024

connglli commented Mar 29, 2023 •

edited

Loading

connglli commented Mar 29, 2023 •

edited

Loading

connglli commented Mar 29, 2023 •

edited

Loading

hzongaro commented Jul 10, 2023 •

edited

Loading