Shark sun.nio.cs.UTF_8$Encoder::encodeArrayLoop throw unhandled signal 4 error on ARM
Gary Benson
gbenson at redhat.com
Wed Aug 18 02:00:25 PDT 2010
Awesome, nice work Xerxes!
Bin Lan wrote:
> Hi Xerxes,
>
> I use LLVM version is 2.7, after applied the two patches which you
> refer to in last email, the issue is fixed, and openjdk can work
> fine.
>
> Thank you very much for your help and suggestion.
>
> Bin Lan
>
> On Tue, 2010-08-17 at 12:25 +0200, Xerxes Rånby wrote:
> > 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
> >
>
>
--
http://gbenson.net/
More information about the distro-pkg-dev
mailing list