JDK-8148783 : aarch64: SEGV running SpecJBB2013
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2016-02-01
  • Updated: 2021-02-01
  • Resolved: 2016-02-09
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 9 Other
9 b107Fixed openjdk8u292Fixed
Related Reports
Relates :  
Description
One of our partners has reported that they are seeing SEGVs running SpecJBB2013.

They have included the attached hs_err log.

I have disassembled the instructions contained in the hs_err log by creating a C program as follows

unsigned char mem[] = {
 0x1f, 0x08, 0x00, 0xf9, 0x70, 0x81, 0x80, 0xf9, 0x1f, 0x0c, 0x00, 0xf9, 0xbf, 0x3a, 0x03, 0xd5,
 0x0a, 0xfc, 0x49, 0xd3, 0xab, 0xf1, 0x7f, 0x90, 0x6b, 0xe8, 0xdf, 0xf2, 0x12, 0x08, 0x00, 0xf9,
 0x7f, 0x79, 0x2a, 0x38, 0xbf, 0x3b, 0x03, 0xd5, 0xfd, 0x7b, 0x43, 0xa9, 0xff, 0x03, 0x01, 0x91,
 0xa8, 0xb8, 0x06, 0x90, 0x1f, 0x01, 0x40, 0xb9, 0xc0, 0x03, 0x5f, 0xd6, 0xf1, 0x03, 0x03, 0x2a, 
};

int main(void)
{
}

(gdb) x/16i 0x4107e8
   0x4107e8 <mem>:      str     xzr, [x0,#16]
   0x4107ec <mem+4>:    prfm    pstl1keep, [x11,#256]
   0x4107f0 <mem+8>:    str     xzr, [x0,#24]
   0x4107f4 <mem+12>:   dmb     ishst
   0x4107f8 <mem+16>:   lsr     x10, x0, #9
   0x4107fc <mem+20>:   adrp    x11, 0x100244000
   0x410800 <mem+24>:   movk    x11, #0xff43, lsl #32
   0x410804 <mem+28>:   str     x18, [x0,#16]
   0x410808 <mem+32>:   strb    wzr, [x11,x10,lsl #0]   <<<<<
   0x41080c <mem+36>:   dmb     ish
   0x410810 <mem+40>:   ldp     x29, x30, [sp,#48]
   0x410814 <mem+44>:   add     sp, sp, #0x40
   0x410818 <mem+48>:   adrp    x8, 0xdb24000
   0x41081c <mem+52>:   ldr     wzr, [x8]
   0x410820 <mem+56>:   ret
   0x410824 <mem+60>:   mov     w17, w3

The SEGV happens on the instruction marked "<<<<<".

This instruction is writing to the card table, X11 should contain the byte map base and X10 the shifted OOP.

The 4 instructions in question are

   0x4107f8 <mem+16>:   lsr     x10, x0, #9
   0x4107fc <mem+20>:   adrp    x11, 0x100244000
   0x410800 <mem+24>:   movk    x11, #0xff43, lsl #32
   0x410804 <mem+28>:   str     x18, [x0,#16]
   0x410808 <mem+32>:   strb    wzr, [x11,x10,lsl #0]

At the time of the SEGV the following were the values in X0, X10, X11.

R0=0x0000ffc8a06c79a8
R10=0x0000007fe450363c
R11=0x0001ff43a02f0000

The fault address register is 0x0001ffc3847f363c

Note that R11 and the fault address register contain invalid aarch64 addresses in that the top 16 bits are not all zeros.

R11 should contain the byte map base. The hs_err log reports the byte map base as

Card table byte_map: [0x0000ffc381ff0000,0x0000ffc3a0000000] byte_map_base: 0x0000ff43a02f0000

However, instead R11 contains the value 0x0001ff43a02f0000

R11 is calculated with the following instructions

   0x4107fc <mem+20>:   adrp    x11, 0x100244000
   0x410800 <mem+24>:   movk    x11, #0xff43, lsl #32

however the address shown in the disassembly above is incorrect because adrp instruction is actually located at 0x0000ffffa04bccf4. If the above instruction were disassembled at the correct address they would be.

0x0000ffffa04bccf4: adrp x11, 0x10000a02f0000
0x0000ffffa04bccf8: movk    x11, #0xff43, lsl #32

Which calculates the incorrect address 0x0001ff43a02f0000 instead of 0x0000ff43a02f0000