Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Gregory Shimansky <gshimansky@gmail.com>
Subject: Re: [dlrvm][jit][opt][x86_64] Running on Jitrino.OPT causes NPE on
 classlib code
Date: Fri, 01 Dec 2006 17:07:55 +0300
Lines: 94
Message-ID: <ekpcvs$hl9$1@sea.gmane.org>
References: <eknt03$sk7$1@sea.gmane.org> <eknuk6$sm$1@sea.gmane.org>
 <469bff730611302150r793b34b7sdf7de6a6b4f5f071@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
In-Reply-To: <469bff730611302150r793b34b7sdf7de6a6b4f5f071@mail.gmail.com>
Sender: news <news@sea.gmane.org>

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