harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [dlrvm][jit][opt][x86_64] Running on Jitrino.OPT causes NPE on classlib code
Date Fri, 01 Dec 2006 15:00:16 GMT
I have found the same problem (NPE) while running SpecJBB2005 in -Xem:opt
mode on IA32 platform.
I did a fix (the problem was in memopt pass) and will commit it after
testing on Linux.

If your problem is in memopt too - there is a good chance that my fix will
solve it. To check it run the test with -
XDjit.CS_OPT.arg.optimizer.memopt=off or delete 'memopt' word from
opt.emconf file manually.


On 12/1/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>
> Pavel Ozhdikhin wrote:
> > Gregory,
> >
> > Is it pure x86_64 problem, i.e. did you manage to run all kernel tests
> in
> > -Xem:opt mode on IA32 platforms?
>
> Yes I wouldn't do any commits if these tests failed on ia32.
>
> > Also when did you manage to pass kernel test on X86_64/-Xem:opt last
> time?
> > Hope this info will help to identify the issue. It looks like many
> > instabilities were introduced with the latest commits to DRLVM and this
> > might be one of them.
>
> Looking at my commits history, it looks like the last time I had a
> successful tests run on x86_64 is r480110 on Tuesday.
>
> The bug doesn't seem to be instability. It is quite stably reproducible
> in the same place. I'll try to find more details, like instruction which
> causes SIGSEGV.
>
> > On 12/1/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> >>
> >> Gregory Shimansky wrote:
> >> > Hello
> >> >
> >> > Today while trying to run acceptance tests on x86_64 I've found that
> >> > kernel tests fail from the first test in pure Jitrino.OPT (-Xem:opt)
> >> > mode. I've tried running simple hello world application, and it does
> >> not
> >> > work any more. The NPE happens in class loader code before the main
> >> class.
> >> >
> >> > I know x86_64 is still not a very stable architecture, but this is
> >> > clearly a regression. I try to do all my commits checking on x86_64
> >> > Linux. Starting from today no program work at all. This is strange
> >> > considering that I didn't see any significant commits to Jitrino for
> >> the
> >> > last 2 days.
> >> >
> >> > I've reproduced it on SuSE9 x86_64 and Gentoo x86_64. On SuSE10
> x86_64
> >> > something even worse has happened, need to investigate if anything at
> >> > all works on it so far (I mean Harmony, the system itself is ok).
> >>
> >> On SuSE10 the same problem is reproducible. In normal conditions hello
> >> world application is executed, on opt it fails with NPE.
> >>
> >> > Here is the stack trace. If I understand it correctly, the code
> >> SIGSEGVs
> >> > in java.net.URLClassLoader.getPermissions and the signal is treated
> as
> >> > hardware NPE.
> >> >
> >> > gashiman@mstmrtd106 ~/work/tests
> >> > $
> >> >
> ../em64t/trunk/working_vm/build/lnx_em64t_gcc_debug/deploy/jre/bin/java
> >> > Hello
> >> > Hello
> >> >
> >> > gashiman@mstmrtd106 ~/work/tests
> >> > $
> >> >
> ../em64t/trunk/working_vm/build/lnx_em64t_gcc_debug/deploy/jre/bin/java
> >> > -Xem:opt Hello
> >> > Uncaught exception in main:
> >> > java.lang.NullPointerException
> >> >         at java.net.URLClassLoader.getPermissions(URLClassLoader.java
> )
> >> >         at
> >> > java.lang.ClassLoader$SystemClassLoader.getPermissions(Unknown
> Source)
> >> >         at
> >> java.security.SecureClassLoader.getPD(SecureClassLoader.java)
> >> >         at
> >> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java
> :70)
> >> >         at java.net.URLClassLoader.findClassImpl(URLClassLoader.java
> >> :1137)
> >> >         at java.net.URLClassLoader$4.run(URLClassLoader.java)
> >> >         at java.net.URLClassLoader$4.run(URLClassLoader.java:1)
> >> >         at java.security.AccessController.doPrivilegedImpl(Unknown
> >> Source)
> >> >         at java.security.AccessController.doPrivileged(Unknown
> Source)
> >> >         at java.net.URLClassLoader.findClass(URLClassLoader.java:621)
> >> >         at java.lang.ClassLoader.loadClass(Unknown Source)
> >> >         at java.lang.ClassLoader$SystemClassLoader.loadClass(Unknown
> >> > Source)
> >> >         at java.lang.ClassLoader.loadClass(Unknown Source)
> >> > FAILED to invoke JVM.
> >>
> >>
> >> --
> >> Gregory
> >>
> >>
> >
>
>
> --
> Gregory
>
>


-- 
Mikhail Fursov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message