SIGILL crashes JVM on PPC64 LE

[Volker Simonis]

And I forgot to mention: I've checked and we don't emit vsel
instructions in jdk8 on ppc. So it must be a coincidence that changing
the endianess of the offending instruction yields a valid 'vsel'
instruction.



On Thu, May 12, 2016 at 2:26 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi Gustavo,
>
> thanks for the bug report. The hs_err file you provided indicates that
> this crash happened with Ubuntu's openjdk 8 version. Can you still
> reproduce this with the the newest jdk9 builds?
>
> Also, I can see from the hs_err file that the crash happened in the C2
> compiled method java.util.TimSort.countRunAndMakeAscending which
> doesn't seem to be related to nio and unsafe.
>
> Ideally, you could post an easy test case to reproduce the problem. If
> that's not possible, it would be helpful if you could post the output
> of a failing run with
> "-XX:CompileCommand=print,java.util.TimSort::countRunAndMakeAscending
> -XX:CompileCommand=option,java.util.TimSort::countRunAndMakeAscending,PrintOptoAssembly".
> In order to get the disassembly output for compiled methods you have
> to build the hsdis library from hotspot/src/share/tools/hsdis (it has
> a README with build instructions).
>
> Regards,
> Volker
>
>
> On Thu, May 12, 2016 at 12:32 AM, Gustavo Romero
> <gromero at linux.vnet.ibm.com> wrote:
>> Hi
>>
>> I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE.
>>
>> hs_err log:
>> http://hastebin.com/raw/fovagunaci
>>
>> The application employs methods from both java.nio.ByteBuffer and
>> sun.misc.Unsafe classes in order to write and read from an allocated buffer.
>>
>> A interesting thing is that after debugging the instruction that caused the
>> said SIGILL:
>>
>>    0x3fff902839a4:      cmpwi   cr6,r17,0
>>    0x3fff902839a8:      beq     cr6,0x3fff90283ae4
>>    0x3fff902839ac:      .long 0xea2f0013 <============ illegal instruction
>>    0x3fff902839b0:      add     r15,r15,r17
>>    0x3fff902839b4:      add     r14,r17,r14
>>
>> I found that when its endianness is changed it turns out to be a valid
>> instruction: vsel v24,v0,v5,v31
>>
>> However, I'm still unable to determine if it's an application issue, something
>> with JVM unsafe interface code, or something else.
>>
>> Any clue on how to narrow down this SIGILL?
>>
>> Thank you!
>>
>> Regards,
>> Gustavo
>>