SIGILL crashes JVM on PPC64 LE

Tue May 31 01:31:10 UTC 2016

Hi Volker

The following test case has been isolated by Hiroshi Horii and generates
the illegal instruction, crashing the JVM on PPC64 LE:

UnalignedUnsafeAccess.java:
http://hastebin.com/raw/uqegukific

$ javac UnalignedUnsafeAccess.java
$ java -Xcomp -Xbatch UnalignedUnsafeAccess

The issue can be reproduced on OpenJDK 8 downstream, OpenJDK 8, and
OpenJDK 9 - hs_err logs:

OpenJDK 9, tag 0be6f4f5d186 jdk-9+120:
http://hastebin.com/raw/ecuhukutur

OpenJDK 8, tag 5aaa43d91c73 tip:
http://hastebin.com/raw/ipohoyafos

OpenJDK 8 downstream:

Ubuntu 16.04 LTS
build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14
http://hastebin.com/raw/yetizebofo

RHEL 7.2:
build 1.8.0_91-b14
http://hastebin.com/raw/irequfawaw

The crash happens when an illegal instruction - 0xea2f0013 - is executed.

The backtrace shows:

Stack: [0x00003fff56030000,0x00003fff56430000],  sp=0x00003fff5642b8d0,  free space=4078k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x162104]  loadI2LNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x194
V  [libjvm.so+0x8ece28]  Compile::fill_buffer(CodeBuffer*, unsigned int*)+0x4e8
V  [libjvm.so+0x368e08]  Compile::Code_Gen()+0x3c8
V  [libjvm.so+0x369e04]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0xf64
V  [libjvm.so+0x271380]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x1f0
V  [libjvm.so+0x3785a4]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd54
V  [libjvm.so+0x379dc8]  CompileBroker::compiler_thread_loop()+0x488
V  [libjvm.so+0xa5de90]  compiler_thread_entry(JavaThread*, Thread*)+0x20
V  [libjvm.so+0xa690c8]  JavaThread::thread_main_inner()+0x178
V  [libjvm.so+0x8c8c10]  java_start(Thread*)+0x170
C  [libpthread.so.0+0x833c]  start_thread+0xfc
C  [libc.so.6+0x12b014]  clone+0xe4

loadI2LNode class is generated according to the following ADL code in
ppc.ad file:

instruct loadI2L(iRegLdst dst, memory mem) %{
  match(Set dst (ConvI2L (LoadI mem)));
  predicate(_kids[0]->_leaf->as_Load()->is_unordered());
  ins_cost(MEMORY_REF_COST);

  format %{ "LWA     $dst, $mem \t// loadI2L" %}
  size(4);
  ins_encode %{
    // TODO: PPC port $archOpcode(ppc64Opcode_lwa);
    int Idisp = $mem$$disp + frame_slots_bias($mem$$base, ra_);
    __ lwa($dst$$Register, Idisp, $mem$$base$$Register);
  %}
  ins_pipe(pipe_class_memory);
%}

So the generated illegal instruction comes from:
lwa 17,17,15  (DS-form: lwa RT, DS, RA)

As DS field must always be 4-byte aligned (i.e. DS field is always
concatenated with 0b00), 17 as DS (middle 17 value) is illegal,
generating the illegal instruction in question:

11101010000000000000000000000010: LWA
00000010001000000000000000000000: 17
00000000000000000000000000010001: 17
00000000000011110000000000000000: 15
--------------------------------
11101010001011110000000000010011: 0xEA2F0013 => Illegal instruction

The following change is proposed to fix the issue and deals with the
unaligned displacements:

OpenJDK 9 webrev:
81.de.7a9f.ip4.static.sl-reverse.com./illegal/9

OpenJDK 8 webrev:
81.de.7a9f.ip4.static.sl-reverse.com./illegal/8

Could we open a JIRA ticket regarding this issue in order to include it
in the webrev?

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
>>>
> 