SIGILL crashes JVM on PPC64 LE

Gustavo Romero gromero at
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:

$ javac
$ 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:

OpenJDK 8, tag 5aaa43d91c73 tip:

OpenJDK 8 downstream:

Ubuntu 16.04 LTS
build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14

RHEL 7.2:
build 1.8.0_91-b14

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  []  loadI2LNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x194
V  []  Compile::fill_buffer(CodeBuffer*, unsigned int*)+0x4e8
V  []  Compile::Code_Gen()+0x3c8
V  []  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0xf64
V  []  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x1f0
V  []  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd54
V  []  CompileBroker::compiler_thread_loop()+0x488
V  []  compiler_thread_entry(JavaThread*, Thread*)+0x20
V  []  JavaThread::thread_main_inner()+0x178
V  []  java_start(Thread*)+0x170
C  []  start_thread+0xfc
C  []  clone+0xe4

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

instruct loadI2L(iRegLdst dst, memory mem) %{
  match(Set dst (ConvI2L (LoadI mem)));

  format %{ "LWA     $dst, $mem \t// loadI2L" %}
  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);

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:

OpenJDK 8 webrev:

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

Thank you!

Best regards,

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> 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> wrote:
>>> Hi
>>> I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE.
>>> hs_err log:
>>> 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

More information about the hotspot-dev mailing list