RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC

Roland Westrelin roland.westrelin at oracle.com
Tue Feb 23 09:25:25 UTC 2016


Thanks for looking at this, Vladimir.

> Use macroassembler instruction signx() for sign extension. Otherwise it is good.

Ok.

> Do you know where move32_64() is called from in this case? Compiled code should clean upper bits for int arguments.

If you look at the jtreg test case, c2 compiles the “compiled” method as:

000   B1: # B3 B2 <- BLOCK HEAD IS JUNK   Freq: 1
000        ! stack bang (272 bytes)
        SAVE   R_SP,-144,R_SP
014        SLL    R_I0,#2,R_O0
018          CALL,static  ; NOP ==>  TestDirtyInt::test
        # TestDirtyInt::compiled @ bci:3  L[0]=_
        # OopMap{off=32}
020
020   B2: #        N1 <- B1  Freq: 0.99998
        # Block is sole successor of call
020 +   MOV    R_O0,R_I0        ! spill
024 +    SETHI  #PollAddr,L0     ! Load Polling address
  LDX    [L0],G0  !Poll for Safepointing
  RET
     RESTORE
038 +    ! return
038
038   B3: #  N1 <- B1  Freq: 1e-05
038        ! exception oop is in R_O0; no code emitted
038 +        MOV    R_O0,R_I0        ! spill
03c +    RESTORE
040 +    Jmp    rethrow_stub
040

so c2 doesn't clean the upper bits before the native call. move32_64 is then called by the compiled native wrapper on the int method argument.

Roland.

> 
> Thanks,
> Vladimir
> 
> On 2/22/16 2:05 AM, Roland Westrelin wrote:
>> Native code is passed an int (in a 64 bit register) which has some bits set in the upper 32 bit half. The native code uses that value for an address computation. That results in a wrong memory access. From a few experiments with code generated by gcc, it seems it expects values to be clean on function entry. The fix cleans the 32 bit value before the native call.
>> 
>> http://cr.openjdk.java.net/~roland/8148353/webrev.00/
>> 
>> Roland.
>> 



More information about the hotspot-compiler-dev mailing list