SIGILL crashes JVM on PPC64 LE

[Gustavo Romero]

Hi Volker

I'm not sure, but it seems that the bytecode i2l is wrong for some
reason. It should be mapped to extsw asm instruction I think. Is
there just one code path that controls this mapping on PPC?

Thank you.

Regards,
Gustavo

On 16-05-2016 15:25, Gustavo Romero wrote:
> Hi Volker
> 
> Thanks for inspecting the Hotspot crash log.
> 
> At the moment it's no possible, AFIAK - and as I could try - to run
> Cassandra on OpenJDK 9. It will hit another missing class issue before
> it runs into the SIGILL issue.
> 
> I'm still trying to reproduce it with an easy test case.
> 
> However, I provide the C2 compiled method disasm:
> 
> hs_err log:
> http://hastebin.com/raw/orufukacos
> 
> hs_err method disasm:
> http://hastebin.com/raw/owoxamodok
> 
> Source for one of the four problematic classes that will crash JVM when
> compiled (we can see them in hs_err method disasm comments):
> java/org/apache/cassandra/db/rows/NativeCell.java#L133
> https://goo.gl/Uefq8Y
> 
> Thanks for letting me know that `isel` is never emitted.
> 
> Thank you!
> 
> Best regards,
> Gustavo
> 
> On 12-05-2016 09:39, Volker Simonis wrote:
>> 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
>>>>
>>
>