Shark sun.nio.cs.UTF_8$Encoder::encodeArrayLoop throw unhandled signal 4 error on ARM

Tue Aug 17 03:25:50 PDT 2010

On 2010-08-17 04:03, Bin Lan wrote:
> Testcase:
>
> public class HelloLoop {
>
> 	public static void main(String[] args)  {
> 		
> 		HelloLoop hello=new HelloLoop();
> 		hello.printOut();
>         }
> 	
> 	private void printOut()
> 	{
>         for(int i=0;i<20000;i++)
> 		{
>         	System.out.println("hello world "+i);
> 		}
> 	}
> }
> ENV:  
>    Hardware: Mindspeed C100
>    OS:  embed Linux 
>
> How to reproduce:
>   root at comcerto100:/root> java -XX:+SharkTraceInstalls  HelloLoop 
>   hello world 0
> hello world 1
> hello world 2
> hello world 3
> hello world 4
> hello world 5
> hello world 6
> hello world 7
> hello world 8
> hello world 9
> ...
> hello world 10305
> hello world 10306
> hello world 10307
> hello world 10308
>  [0x43662010-0x43662f6c): sun.nio.cs.UTF_8$Encoder::encodeArrayLoop
> (3932 bytes code)
> hello world 10309#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (os_linux_zero.cpp:236), pid=1729, tid=1086248080
> #  Error: caught unhandled signal 4
>
>   
Signal 4 SIGILL illegal instruction usually indicate that the JITed code
have taken a branch into garbage memory.
It can also some times indicate that LLVM have actually JITed a broken
instruction
... or a instruction not supported by your ARM core, since the LLVM JIT
defaults to use armv4 instructions and all those are supported by you
core means that you should not see any signal 4 SIGILL issues under
normal circumstances.

I have tested your testcase on my various ARM hardware and have been
unable to reproduce the bug.

All Shark versions tested below here have been run in combination with
patched LLVM versions in order to work around LLVM JIT bugs.
I think you need to patch your LLVM version as well. See the end of the
mail for lists of patches.

passed on ubuntu 9.04: running shark using llvm 2.8svn and
icedtea6-pre1.9 on armv7  hardware
    compiled using gcc 4.3.3
    xerxes at xerxes:~$ uname -a
    Linux xerxes 2.6.28-15-araneo #50fsl1araneo19-Ubuntu PREEMPT Mon Jan
25 15:54:27 UTC 2010 armv7l GNU/Linux
    xerxes at xerxes:~$ java -version
    java version "1.6.0_20"
    OpenJDK Runtime Environment (IcedTea6 1.9pre+rdd4d9f50ac7c) (Ubuntu
build 1.6.0_20-b20)
    OpenJDK Shark VM (build 17.0-b16, mixed mode)

passed on debian squeese: running shark using llvm 2.6 and icedtea6-1.8
on armv5 hardware
    compiled using gcc 4.4.4
    xranby at stora:~$ uname -a
    Linux stora 2.6.22.18-Netgear #4 Thu Sep 3 13:29:25 EDT 2009
armv5tejl GNU/Linux
    xranby at stora:~$ java -shark
-version                                          
    java version "1.6.0_18"
    OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-1)
    OpenJDK Shark VM (build 14.0-b16, mixed mode)

passed on ubuntu 9.04 using llvm 2.7 and icedtea6-1.8 on armv7 omap hardware
    compiled using gcc 4.5 using openembedded targeting armv4 instructionset
    xerxes at overo:~$
/usr/src/openembedded/shark-test/26jul-shark-armv4/bin/java -shark -version
    java version "1.6.0_18"
    OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8)
    OpenJDK Shark VM (build 14.0-b16, mixed mode)

xerxes at overo:~$
/usr/src/openembedded/shark-test/26jul-shark-armv4/bin/java -shark
-XX:+SharkTraceInstalls -XX:CompileThreshold=2000 HelloLoop
 [0x67e89010-0x67e89320): java.lang.String::hashCode (784 bytes code)
hello world 0
hello world 1
hello world 2
hello world 3
hello world 4
hello world 5
hello world 6
hello world 7
hello world 8
hello world 9 [0x67e89360-0x67e8a1c4):
sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (3684 bytes code)

hello world 10
hello world 11

...

hello world 26
hello world 27
hello world 28 [0x67e8a200-0x67e8aab8): java.lang.String::indexOf (2232
bytes code)

... a lot of hellos and 70 jited methods later

hello world 19992
hello world 19993
hello world 19994
hello world 19995
hello world 19996
hello world 19997
hello world 19998
hello world 19999
xerxes at overo:~$

success!

> //////////////////////////////////////////////////////////////////////
>
> I found a same bug
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=319 , the bug was
> fixed. 

This fixed bug behaves a bit differently than the bug you are
experiencing since pr319 triggered a regular segfault.

> But I don't know why the bug occurred?
>   
Honestly we are still a bit unsure why pr319 occurred since we never
investigated it more closely by creating a gdb backtrace,

Most likely the pr319 bug got fixed during October 2009 while inventing
a workaround for a armv4 indirect branch JIT bug found in LLVM.
http://labb.zafena.se/?p=257
Today i would categorize pr319 as a duplicate of
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=434
This branch bug have now fixed properly when using Shark in combination
with LLVM 2.8svn from LLVM upstream. LLVM 2.8svn contain the first
implementation of the ARM JIT that work on armv4 and later out of the box.

sun.nio.cs.UTF_8$Encoder::encodeArrayLoop are usually one of the first
larger methods to get jited by Shark and therefore are quite likely to
trigger any LLVM JIT issue if there are any instability in the LLVM JIT.

We still need a GDB backtrace in order to find out and categorize why
your JITed  sun.nio.cs.UTF_8$Encoder::encodeArrayLoop hits a Signal 4
SIGILL.
> Does anyone can help me solve the issue or some suggestion? I appreciate
> for your help.
>   

What LLVM version do you use?

At a minimal if you compile LLVM yourself then you must patch the LLVM
JIT for ARM to mainly work around two LLVM JIT bugs:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=434 - the armv4
indirect branch JIT bug as mentioned above. - fixed in llvm 2.8 and later
and
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=399 - this LLVM
bug hits for long running applications when the JITed code spans over
more than 32mb of RAM on ARM.

There do exist other LLVM JIT bugs that triggers if you try to enable
armv6 instructions and later or enable the use of a VFP  FPU units NEON
unit etc etc.

Since LLVM dont make bugfix dot releases the various Linux distributions
have to keep track of all bugfix patches needed to fixes issues reported
by their users to be applied on the various LLVM releases.

The current list of patches we used to stabilize LLVM 2.7 for
Openembedded users are:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/llvm/llvm2.7

Ubuntu currently use these sources for llvm2.7:
https://launchpad.net/ubuntu/+source/llvm-2.7/

and Debian currently uses these set of patches for llvm2.6:
http://patch-tracker.debian.org/package/llvm/2.6-9

> B.R
>
>   

Cheers and have a great day!
Xerxes