-
Bug
-
Resolution: Withdrawn
-
P2
-
17.0.3, 17.0.3-oracle
-
aarch64
-
os_x
We have discovered multiple crashes in GC ( both G1 and parallelGC) on M1 Ultra. ( 20 core arch64 cpu). We see crashes on both OracleJDK17.0.3 and JetBrainsRuntime 17.0.3. Some of them may look like race condition ( G1 bug)
System diagnostic shows the memory is fine.
some analysis of attached jbr_g1.log:
dump of crash site with comments,
x19 - 0x00000003d88a4a28
0x00000003d88a4a28 is pointing into object: java.lang.Class
{0x00000003d88a4a10} - klass: 'java/lang/Class'
- ---- fields (total size 14 words):
- private volatile transient 'classRedefinedCount' 'I' @12 1
- private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0)
crash site:
000000000039de8c ldr w9, [x19, #0x8] // read compressed klass ptr from the object
//next 6 instructions is klass decompression
000000000039de90 adrp x10, 2129 ; 0xbee000
000000000039de94 add x10, x10, #0x4f8
000000000039de98 ldr x11, [x10]
000000000039de9c ldr w10, [x10, #0x8]
000000000039dea0 lsl x9, x9, x10
000000000039dea4 add x0, x9, x11
//decompressed klass pointer is now in x0
000000000039dea8 ldr w9, [x0, #0x8] //x0 is just 0x70, causing a crash
the original value at address object + 8 == [x19+0x8] == x9 >> x10 == 0x70 >> 3 == 0x1c
so at the moment of the crash we had bad value at klassPtr of object 0x00000003d88a4a28, but at the time the hs_err report is generated, jvm can read klass from the object just fine:
0x00000003d88a4a28 is pointing into object: java.lang.Class
{0x00000003d88a4a10} - klass: 'java/lang/Class'
System diagnostic shows the memory is fine.
some analysis of attached jbr_g1.log:
dump of crash site with comments,
x19 - 0x00000003d88a4a28
0x00000003d88a4a28 is pointing into object: java.lang.Class
{0x00000003d88a4a10} - klass: 'java/lang/Class'
- ---- fields (total size 14 words):
- private volatile transient 'classRedefinedCount' 'I' @12 1
- private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0)
crash site:
000000000039de8c ldr w9, [x19, #0x8] // read compressed klass ptr from the object
//next 6 instructions is klass decompression
000000000039de90 adrp x10, 2129 ; 0xbee000
000000000039de94 add x10, x10, #0x4f8
000000000039de98 ldr x11, [x10]
000000000039de9c ldr w10, [x10, #0x8]
000000000039dea0 lsl x9, x9, x10
000000000039dea4 add x0, x9, x11
//decompressed klass pointer is now in x0
000000000039dea8 ldr w9, [x0, #0x8] //x0 is just 0x70, causing a crash
the original value at address object + 8 == [x19+0x8] == x9 >> x10 == 0x70 >> 3 == 0x1c
so at the moment of the crash we had bad value at klassPtr of object 0x00000003d88a4a28, but at the time the hs_err report is generated, jvm can read klass from the object just fine:
0x00000003d88a4a28 is pointing into object: java.lang.Class
{0x00000003d88a4a10} - klass: 'java/lang/Class'