You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/06/07 21:50:20 UTC
[jchevm+classlibadapter] Running classlib tests
With HARMONY-569, HARMONY-572 and a couple of simple hacks - like
removing the -showversion jvm arguments from test runs - I've been able
to run 63% of the classlib tests. I should get more running with a
little more effort. The test results were:
Tests Failures Errors Success rate
5601 360 744 80.29%
which is v. impressive.
Will provide more details of what I had to do to run the tests and some
of the causes of failures in the next couple of days.
Regards,
Mark.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Weldon Washburn <we...@gmail.com>.
Mark,
Indeed impressive! And a big thank you for doing this.
I also want to thank Ivan Volosyuk for his mods to areas like
VMStackWalker, ClassLoader, StackTraceElement, etc. It is an
important contribution.
I look forward to your next email on classlibadapter.
On 6/7/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> Darn impressive.
>
> Mark Hindess wrote:
> > With HARMONY-569, HARMONY-572 and a couple of simple hacks - like
> > removing the -showversion jvm arguments from test runs - I've been able
> > to run 63% of the classlib tests. I should get more running with a
> > little more effort. The test results were:
> >
> > Tests Failures Errors Success rate
> > 5601 360 744 80.29%
> >
> > which is v. impressive.
> >
> > Will provide more details of what I had to do to run the tests and some
> > of the causes of failures in the next couple of days.
> >
> > Regards,
> > Mark.
> >
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Ivan Volosyuk <iv...@gmail.com>.
Wow! I've just wanted to run eclipse :) And it requires a bunch of the
functionality.
Thank you, Mark, it is great to know that I am not only one who
interested in the adapter.
It was quite interesting to get something work. Now, it becoming
increasingly difficult to dig deep into eclipse internal searching for
new failures. It seems that classlib tests can do this task easier.
I am going to do some more hacking at weekend. For now I have one
small fix for ThreadLocal implementation. I will create corresponding
jira today. Btw, it will be good if all such jiras will be linked to
each other as relatives. They will be easy to find.
--
Ivan
2006/6/7, Geir Magnusson Jr <ge...@pobox.com>:
> Darn impressive.
>
> Mark Hindess wrote:
> > With HARMONY-569, HARMONY-572 and a couple of simple hacks - like
> > removing the -showversion jvm arguments from test runs - I've been able
> > to run 63% of the classlib tests. I should get more running with a
> > little more effort. The test results were:
> >
> > Tests Failures Errors Success rate
> > 5601 360 744 80.29%
> >
> > which is v. impressive.
> >
> > Will provide more details of what I had to do to run the tests and some
> > of the causes of failures in the next couple of days.
> >
> > Regards,
> > Mark.
--
Ivan
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Darn impressive.
Mark Hindess wrote:
> With HARMONY-569, HARMONY-572 and a couple of simple hacks - like
> removing the -showversion jvm arguments from test runs - I've been able
> to run 63% of the classlib tests. I should get more running with a
> little more effort. The test results were:
>
> Tests Failures Errors Success rate
> 5601 360 744 80.29%
>
> which is v. impressive.
>
> Will provide more details of what I had to do to run the tests and some
> of the causes of failures in the next couple of days.
>
> Regards,
> Mark.
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Tim Ellison <t....@gmail.com>.
Ivan Volosyuk wrote:
> Yes, I have done this in VMThread.run() method for newly created
> threads. But I have seen no way to do this in JNI's ThreadAttach().
Ah, ok got it.
> Looks like gnu classpath doesn't require any callbacks (like
> thread_attach()) to be called on the attached thread, so the jchevm
> doesn't do this.
and to be fair you wouldn't expect them to without reason.
> That is why in order to use classlib, this place
> needs changes in jchevm and it looks like the same applies to all
> other VMs which use gnu classpath interfaces. That is the problem I am
> talking about.
So you either have to think of ways to subvert ThreadAttach() or delay
the classlib attachment until it comes into (classlib) native code.
Either way sounds like grubby hacks required.
Regards,
Tim
> --
> Ivan
>
> On 6/9/06, Tim Ellison <t....@gmail.com> wrote:
>> Ivan Volosyuk wrote:
>> > Yes, there are a lot of functions without implementation. I have
>> > inserted this exceptions there to fast detect this places. It will
>> > also be a few UnsatisfiedLinkErrors for some missing functions in
>> > java.lang.reflect.Array.
>> > Security is just no-op for now. I have almost zero knowledge in this
>> area.
>> > Most probable reason for the hang in two luni tests is bug or
>> > unimplemented functionality in Thread.java
>> > One of problems in the Thread.java I have no clue how to solve is:
>> > Classlib implementation uses its own thread manager implementation,
>> > jchevm has also its own. Some classlib's native methods implementation
>> > rely on thread_attach() call before them, otherwise they crash. I have
>> > implemented this in VMThread.run(). But JNI ThreadAttach in jchevm
>> > doesn't call classlib's thread_attach(), so threads attached via JNI
>> > will crash classlib.
>>
>> There are requirements on the VM in order to run the classlib native
>> code, like setting up the port library and playing nicely with the
>> thread library. For example, native's monitor operations require that
>> the thread has been attached via hythread_attach() [1].
>>
>> I don't know the JCHEVM code well enough to point to the right place,
>> but performing an hythread_attach() when a JCHEVM thread is
>> created/attached -- and a matching detach -- would be the answer.
>>
>> [1]
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/hythread_8c.html?view=co
>>
>>
>> Regards,
>> Tim
>>
>> > --
>> > Ivan
>> >
>> > On 6/8/06, Mark Hindess <ma...@googlemail.com> wrote:
>> >>
>> >> On 7 June 2006 at 20:50, "Mark Hindess" <ma...@googlemail.com>
>> >> wrote:
>> >> >
>> >> > With HARMONY-569, HARMONY-572 and a couple of simple hacks - like
>> >> > removing the -showversion jvm arguments from test runs - I've been
>> >> > able to run 63% of the classlib tests. I should get more running
>> with
>> >> > a little more effort. The test results were:
>> >> >
>> >> > Tests Failures Errors Success rate
>> >> > 5601 360 744 80.29%
>> >> >
>> >> > which is v. impressive.
>> >>
>> >> I've improved my wrapper script (linux only sorry) to ignore
>> >> -showversion and handle -Xbootclasspath/[ap] appropriately. I've
>> >> attached this to HARMONY-583.
>> >>
>> >> I had to exclude two luni tests which were causing the vm to hang:
>> >>
>> >> tests/api/java/lang/IllegalThreadStateExceptionTest.java
>> >> tests/api/java/lang/ThreadTest.java
>> >>
>> >> But the new test results are:
>> >>
>> >> Tests Failures Errors Success rate
>> >> 8348 1295 892 73.80%
>> >>
>> >> which is progress even though the success rate went down.
>> >>
>> >> Many of the failures share the same root causes so I think this
>> >> figure could improved pretty quickly.
>> >>
>> >> I wish there was a tool to summarise the root failures out of 2000+
>> >> junit test reports! Just scanning at random, the most common errors
>> >> seem to be:
>> >>
>> >> 1)
>> >>
>> >> not implemented
>> >>
>> >> java.lang.RuntimeException: not implemented at
>> >> java.lang.ClassLoader.getResources(ClassLoader.java:224) at
>> >>
>> org.apache.harmony.jndi.internal.EnvironmentReader.readMultipleResourceFiles
>>
>> >>
>> >> (EnvironmentReader.java:227) at
>> >> org.apache.harmony.jndi.internal.EnvironmentReader$2.run
>> >> (EnvironmentReader.java:280) at
>> >> java.security.AccessController.doPrivileged
>> >> (AccessController.java:241) at
>> >>
>> org.apache.harmony.jndi.internal.EnvironmentReader.readApplicationResourceFiles
>>
>> >>
>> >> (EnvironmentReader.java:278) at
>> javax.naming.InitialContext.internalInit
>> >> (InitialContext.java:207) at javax.naming.InitialContext.<init>
>> >> (InitialContext.java:151) at
>> >>
>> org.apache.harmony.jndi.tests.javax.naming.InitialContextMockTest.setUp
>> >> (InitialContextMockTest.java:50)
>> >>
>> >> 2)
>> >>
>> >> not implemented
>> >>
>> >> java.lang.RuntimeException: not implemented at
>> >>
>> org.apache.harmony.kernel.vm.VM.getNonBootstrapClassLoader(VM.java:77) at
>> >> java.io.ObjectInputStream.readObject(ObjectInputStream.java:1942) at
>> >> java.io.ObjectInputStream.readObject(ObjectInputStream.java:1901) at
>> >> javax.security.auth.SubjectTest.test_PrincipalSetInvalidSerForm
>> >> (SubjectTest.java:1297) at java.lang.reflect.Method.invokeNative
>> >> (Method.java) at org.apache.harmony.auth.internal.SecurityTest.runTest
>> >> (SecurityTest.java:109)
>> >>
>> >> 3) Many of the crypto/auth/security tests are failing with
>> >> "implementation
>> >> not found" type errors.
>> >>
>> >> 4)
>> >>
>> >> META-INF/ALICE.SF has invalid digest for Test.class in /var/tmp/
>> >> hyts_resources45209/TestCodeSigners.jar
>> >>
>> >> java.lang.SecurityException: META-INF/ALICE.SF has invalid digest for
>> >> Test.class in /var/tmp/hyts_resources45209/TestCodeSigners.jar at
>> >> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:331) at
>> >> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:242) at
>> >> java.util.jar.JarFile.getInputStream(JarFile.java:340) at
>> >>
>> org.apache.harmony.archive.tests.java.util.jar.JarEntryTest.test_getCodeSigners
>>
>> >>
>> >> (JarEntryTest.java:122) at
>> >> java.lang.reflect.Method.invokeNative(Method.java)
>> >>
>> >> Regards,
>> >> Mark.
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Attaching threads to classlib (was: Re: [jchevm+classlibadapter]
Running classlib tests)
Posted by Tim Ellison <t....@gmail.com>.
Archie Cobbs wrote:
> Ivan Volosyuk wrote:
>> IMHO, Archie's suggestion is simplier and less intrusive, as the
>> function Thread.attachInternal() can be native function implemented in
>> classlibadapter itself.
>
> But Graeme is correct in that there could be initialization delay.
> I.e., if we're following the normal rules of Java, all the initialization
> associated with java.lang.Object, java.lang.String, etc. will have to
> occur before the very first thread can invoke any methods in
> java.lang.Thread (even if native).
>
> The idea is salvagable if we have a special classlib-specific launcher
> (i.e., C program using the JNI invocation interface to launch the JVM)
We do have a Harmony launcher [1] that sets up the VMI structure to pass
through to the VM and uses JNI invocation.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/native-src/shared/launcher/
> which did the very first thread_attach() for the main thread. Then all
> the other threads could use Thread.attachThread() or whatever without
> all the initialization delay.
We could attach the primordial thread in the launcher but of course that
would not help when the VM is embedded in some other program and doesn't
have the launcher's help.
VMs should also be aware that attaching a thread that is already
attached will set the hythread_t pointer arg to the original struct, and
increment the attachment count.
> Yet another idea (probably not feasible) would be for classlib to:
>
> (a) check whether thread_attach() has been called yet for the current
> thread in any native method that requires this to be so, and if not,
> go ahead and do it itself
This is do-able too by hijacking the THREAD_SELF macro, but a bit of a
hack, and doesn't give a good story for thread death.
> (b) store its state in a ThreadLocal (so cleanup would be automatic)
Well, unless you have to do some work on the thread death, if it were
just TLS data then yes.
Regards,
Tim
> This would eliminate the requirement for the VM to be classlib-aware.
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Archie Cobbs <ar...@dellroad.org>.
Ivan Volosyuk wrote:
> IMHO, Archie's suggestion is simplier and less intrusive, as the
> function Thread.attachInternal() can be native function implemented in
> classlibadapter itself.
But Graeme is correct in that there could be initialization delay.
I.e., if we're following the normal rules of Java, all the initialization
associated with java.lang.Object, java.lang.String, etc. will have to
occur before the very first thread can invoke any methods in
java.lang.Thread (even if native).
The idea is salvagable if we have a special classlib-specific launcher
(i.e., C program using the JNI invocation interface to launch the JVM)
which did the very first thread_attach() for the main thread. Then all
the other threads could use Thread.attachThread() or whatever without
all the initialization delay.
Yet another idea (probably not feasible) would be for classlib to:
(a) check whether thread_attach() has been called yet for the current
thread in any native method that requires this to be so, and if not,
go ahead and do it itself
(b) store its state in a ThreadLocal (so cleanup would be automatic)
This would eliminate the requirement for the VM to be classlib-aware.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 6/19/06, Graeme Johnson <Gr...@ca.ibm.com> wrote:
> Archie Cobbs <ar...@dellroad.org> wrote on 06/19/2006 10:16:42 AM:
> > Ivan Volosyuk wrote:
> > > As far as I can see classlib uses port library libprt.so which is
> > > intended to be used by VM as low level layer above OS threading
> > > system. Some kind of abstraction of underlying OS primitives. The port
> > > library is widely used in classlib. The port library data is
> > > accessible via TLS (it is done imho to support multi VM environments).
> > > To initialize each thread's TLS pointer to the port library the
> > > thread_attach() function is needed.
> >
> > We could handle this in the following manner: let's define two
> well-known
> > static native methods (Thread.internaAttach() and
> Thread.internalDetach()).
> > Then, if these exist, the VM will invoke them from within each thread at
> > the beginning and ending of its lifetime.
> >
> > This would require a simple change to the classlib code and any classlib
> > VM's. However, it would be a good change, because it would be making
> > explicit a VM-classlib dependency that is now implicit.
> >
> > Thoughts on this approach?
>
> Ivan's description of the libraries is accurate. The port library
> (libhyprt.so) provides an abstraction of the underlying OS, and is built
> on top of the threading library (libhythr.so). The port library uses
> TLS for per-thread error code/message translation, and monitors to
> protect data structures in the NLS components.
>
> As Tim Ellison indicated hythread_attach() must be called by each thread
> that uses thread library functionality. The hythread_attach() does
> one-time initialization of per-thread state, and must be cleaned up by a
> corresponding call to hythread_detach().
>
> Logically the VM's implementation of the JNI Invocation API has the most
> accurate knowledge of when a thread needs to be attached/detached.
> Logically, hythread_attach() should occur in the implementation of the
> JNI AttachCurrentThread() function, with the corresponding teardown
> occurring in DetachCurrentThread().
>
> You want these calls to occur as early as possible so that the thread is
> free to make port and thread library calls. Putting the initialization
> into
> Java code leaves a potentially large window between the thread starting to
> run and the initialization happening.
>
> You might have more success using (or adding) an event reporting callback.
> The JVMTI thread start/end events should be fired at right point to do the
>
> attach/detach. Is using / piggy-backing on JVMTI event reporting an
> option
> in your case?
>
> Graeme Johnson
> J9 VM Team, IBM Canada.
>
Very interesting idea.
Let me summarise my knowledge:
- Classlib requires thread_attach() to be called before calling some
of classlib java code (as the native implementation may rely on
specific thread's TLS state)
- jchevm (and number of other VM tied to classpath) know nothing about
classlib's port library - libprt.so
- there is a glue layer - classlibadapter which works as a bridge
between classpath-bound VMs (e.g. jchevm) and classlib.
So, you suggests, to implement in classlibadapter a JVMTI agent which
will handle thread attach JVMTI events? This could be a solution for
every JVMTI-aware VM. Unfortunately, AFAIK, jchevm doesn't support
JVMTI, and I am don't have the information about the support in other
classpath-bound VMs.
IMHO, Archie's suggestion is simplier and less intrusive, as the
function Thread.attachInternal() can be native function implemented in
classlibadapter itself.
--
Ivan
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Ivan Volosyuk <iv...@gmail.com>.
It even don't require change to classlib, but rather to classlibadapter.
The main drawback of this approach: it requires changes to _all_ VMs
which works successfully with gnu classpath to work with
classlib/classlibadapter. There is no other visible obstacles.
--
Ivan
On 6/19/06, Archie Cobbs <ar...@dellroad.org> wrote:
> Ivan Volosyuk wrote:
> > As far as I can see classlib uses port library libprt.so which is
> > intended to be used by VM as low level layer above OS threading
> > system. Some kind of abstraction of underlying OS primitives. The port
> > library is widely used in classlib. The port library data is
> > accessible via TLS (it is done imho to support multi VM environments).
> > To initialize each thread's TLS pointer to the port library the
> > thread_attach() function is needed.
>
> We could handle this in the following manner: let's define two well-known
> static native methods (Thread.internaAttach() and Thread.internalDetach()).
> Then, if these exist, the VM will invoke them from within each thread at
> the beginning and ending of its lifetime.
>
> This would require a simple change to the classlib code and any classlib
> VM's. However, it would be a good change, because it would be making
> explicit a VM-classlib dependency that is now implicit.
>
> Thoughts on this approach?
>
> -Archie
--
Ivan
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Graeme Johnson <Gr...@ca.ibm.com>.
Archie Cobbs <ar...@dellroad.org> wrote on 06/19/2006 10:16:42 AM:
> Ivan Volosyuk wrote:
> > As far as I can see classlib uses port library libprt.so which is
> > intended to be used by VM as low level layer above OS threading
> > system. Some kind of abstraction of underlying OS primitives. The port
> > library is widely used in classlib. The port library data is
> > accessible via TLS (it is done imho to support multi VM environments).
> > To initialize each thread's TLS pointer to the port library the
> > thread_attach() function is needed.
>
> We could handle this in the following manner: let's define two
well-known
> static native methods (Thread.internaAttach() and
Thread.internalDetach()).
> Then, if these exist, the VM will invoke them from within each thread at
> the beginning and ending of its lifetime.
>
> This would require a simple change to the classlib code and any classlib
> VM's. However, it would be a good change, because it would be making
> explicit a VM-classlib dependency that is now implicit.
>
> Thoughts on this approach?
Ivan's description of the libraries is accurate. The port library
(libhyprt.so) provides an abstraction of the underlying OS, and is built
on top of the threading library (libhythr.so). The port library uses
TLS for per-thread error code/message translation, and monitors to
protect data structures in the NLS components.
As Tim Ellison indicated hythread_attach() must be called by each thread
that uses thread library functionality. The hythread_attach() does
one-time initialization of per-thread state, and must be cleaned up by a
corresponding call to hythread_detach().
Logically the VM's implementation of the JNI Invocation API has the most
accurate knowledge of when a thread needs to be attached/detached.
Logically, hythread_attach() should occur in the implementation of the
JNI AttachCurrentThread() function, with the corresponding teardown
occurring in DetachCurrentThread().
You want these calls to occur as early as possible so that the thread is
free to make port and thread library calls. Putting the initialization
into
Java code leaves a potentially large window between the thread starting to
run and the initialization happening.
You might have more success using (or adding) an event reporting callback.
The JVMTI thread start/end events should be fired at right point to do the
attach/detach. Is using / piggy-backing on JVMTI event reporting an
option
in your case?
Graeme Johnson
J9 VM Team, IBM Canada.
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Archie Cobbs <ar...@dellroad.org>.
Ivan Volosyuk wrote:
> As far as I can see classlib uses port library libprt.so which is
> intended to be used by VM as low level layer above OS threading
> system. Some kind of abstraction of underlying OS primitives. The port
> library is widely used in classlib. The port library data is
> accessible via TLS (it is done imho to support multi VM environments).
> To initialize each thread's TLS pointer to the port library the
> thread_attach() function is needed.
We could handle this in the following manner: let's define two well-known
static native methods (Thread.internaAttach() and Thread.internalDetach()).
Then, if these exist, the VM will invoke them from within each thread at
the beginning and ending of its lifetime.
This would require a simple change to the classlib code and any classlib
VM's. However, it would be a good change, because it would be making
explicit a VM-classlib dependency that is now implicit.
Thoughts on this approach?
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [jchevm+classlibadapter] Running classlib tests
Posted by Nathan Beyer <nb...@kc.rr.com>.
What are you using for the luni-kernel-stubs? Are you using a
classlibadapter replacement or the actual stubs project? If it's a
replacement, then you may want to verify that the replacement classes are in
sync with the current state of the stubs project.
-Nathan
> -----Original Message-----
> From: Archie Cobbs [mailto:archie@dellroad.org]
> Sent: Saturday, June 10, 2006 3:12 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [jchevm+classlibadapter] Running classlib tests
>
> Dumb question.. how do I fix this problem building classlibadapter:
>
> $ sh build.sh
> Using CLASSLIB_HOME = /home/archie/harmony-enhanced/classlib/trunk
> ----------
> 1. ERROR in ./java/lang/ref/Reference.java
> (at line 1)
> /* Copyright 1998, 2005 The Apache Software Foundation or its
> licensors, as applicable
> ^^
> The type Reference is not generic; it cannot be parameterized with
> arguments
> <? extends T>
> ----------
> 1 problem (1 error)
>
> Thanks,
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Archie Cobbs <ar...@dellroad.org>.
Dumb question.. how do I fix this problem building classlibadapter:
$ sh build.sh
Using CLASSLIB_HOME = /home/archie/harmony-enhanced/classlib/trunk
----------
1. ERROR in ./java/lang/ref/Reference.java
(at line 1)
/* Copyright 1998, 2005 The Apache Software Foundation or its
licensors, as applicable
^^
The type Reference is not generic; it cannot be parameterized with arguments
<? extends T>
----------
1 problem (1 error)
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Ivan Volosyuk <iv...@gmail.com>.
As far as I can see classlib uses port library libprt.so which is
intended to be used by VM as low level layer above OS threading
system. Some kind of abstraction of underlying OS primitives. The port
library is widely used in classlib. The port library data is
accessible via TLS (it is done imho to support multi VM environments).
To initialize each thread's TLS pointer to the port library the
thread_attach() function is needed.
--
Ivan
On 6/9/06, Archie Cobbs <ar...@dellroad.org> wrote:
> Ivan Volosyuk wrote:
> > Yes, I have done this in VMThread.run() method for newly created
> > threads. But I have seen no way to do this in JNI's ThreadAttach().
> > Looks like gnu classpath doesn't require any callbacks (like
> > thread_attach()) to be called on the attached thread, so the jchevm
> > doesn't do this. That is why in order to use classlib, this place
> > needs changes in jchevm and it looks like the same applies to all
> > other VMs which use gnu classpath interfaces. That is the problem I am
> > talking about.
>
> I haven't looked at the code so these may be questions arising from
> ignorance..
>
> What native code in classlib requires special thread support and why?
>
> Could we simply override those classes and eliminate this need, and
> just remove (or ignore) the classlib thread stuff?
>
> Why can't whatever code uses thread_attach() use the normal JNI methods
> for thread management instead?
>
> JCHEVM should be compatible with any native library that adheres to
> the JNI spec.. but if it requires other "backdoor" functions to be
> supplied by the JVM, then in theory we can eliminate that requirement,
> because after all normal Classpath doesn't require it and it works
> just fine.
>
> Thanks,
> -Archie
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Archie Cobbs <ar...@dellroad.org>.
Ivan Volosyuk wrote:
> Yes, I have done this in VMThread.run() method for newly created
> threads. But I have seen no way to do this in JNI's ThreadAttach().
> Looks like gnu classpath doesn't require any callbacks (like
> thread_attach()) to be called on the attached thread, so the jchevm
> doesn't do this. That is why in order to use classlib, this place
> needs changes in jchevm and it looks like the same applies to all
> other VMs which use gnu classpath interfaces. That is the problem I am
> talking about.
I haven't looked at the code so these may be questions arising from
ignorance..
What native code in classlib requires special thread support and why?
Could we simply override those classes and eliminate this need, and
just remove (or ignore) the classlib thread stuff?
Why can't whatever code uses thread_attach() use the normal JNI methods
for thread management instead?
JCHEVM should be compatible with any native library that adheres to
the JNI spec.. but if it requires other "backdoor" functions to be
supplied by the JVM, then in theory we can eliminate that requirement,
because after all normal Classpath doesn't require it and it works
just fine.
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Archie Cobbs <ar...@dellroad.org>.
Ivan Volosyuk wrote:
> Yes, I have done this in VMThread.run() method for newly created
> threads. But I have seen no way to do this in JNI's ThreadAttach().
> Looks like gnu classpath doesn't require any callbacks (like
> thread_attach()) to be called on the attached thread, so the jchevm
> doesn't do this. That is why in order to use classlib, this place
> needs changes in jchevm and it looks like the same applies to all
> other VMs which use gnu classpath interfaces. That is the problem I am
> talking about.
One thing to try would be adding a call to VMThread.attach() in
the Thread(VMThread, String, int, boolean) constructor, which is
the constructor used for native threads.
However, this method is not invoked in a native thread until the first
time Thread.currentThread() is invoked -- that may or may not
be soon enough.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Ivan Volosyuk <iv...@gmail.com>.
Yes, I have done this in VMThread.run() method for newly created
threads. But I have seen no way to do this in JNI's ThreadAttach().
Looks like gnu classpath doesn't require any callbacks (like
thread_attach()) to be called on the attached thread, so the jchevm
doesn't do this. That is why in order to use classlib, this place
needs changes in jchevm and it looks like the same applies to all
other VMs which use gnu classpath interfaces. That is the problem I am
talking about.
--
Ivan
On 6/9/06, Tim Ellison <t....@gmail.com> wrote:
> Ivan Volosyuk wrote:
> > Yes, there are a lot of functions without implementation. I have
> > inserted this exceptions there to fast detect this places. It will
> > also be a few UnsatisfiedLinkErrors for some missing functions in
> > java.lang.reflect.Array.
> > Security is just no-op for now. I have almost zero knowledge in this area.
> > Most probable reason for the hang in two luni tests is bug or
> > unimplemented functionality in Thread.java
> > One of problems in the Thread.java I have no clue how to solve is:
> > Classlib implementation uses its own thread manager implementation,
> > jchevm has also its own. Some classlib's native methods implementation
> > rely on thread_attach() call before them, otherwise they crash. I have
> > implemented this in VMThread.run(). But JNI ThreadAttach in jchevm
> > doesn't call classlib's thread_attach(), so threads attached via JNI
> > will crash classlib.
>
> There are requirements on the VM in order to run the classlib native
> code, like setting up the port library and playing nicely with the
> thread library. For example, native's monitor operations require that
> the thread has been attached via hythread_attach() [1].
>
> I don't know the JCHEVM code well enough to point to the right place,
> but performing an hythread_attach() when a JCHEVM thread is
> created/attached -- and a matching detach -- would be the answer.
>
> [1]
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/hythread_8c.html?view=co
>
> Regards,
> Tim
>
> > --
> > Ivan
> >
> > On 6/8/06, Mark Hindess <ma...@googlemail.com> wrote:
> >>
> >> On 7 June 2006 at 20:50, "Mark Hindess" <ma...@googlemail.com>
> >> wrote:
> >> >
> >> > With HARMONY-569, HARMONY-572 and a couple of simple hacks - like
> >> > removing the -showversion jvm arguments from test runs - I've been
> >> > able to run 63% of the classlib tests. I should get more running with
> >> > a little more effort. The test results were:
> >> >
> >> > Tests Failures Errors Success rate
> >> > 5601 360 744 80.29%
> >> >
> >> > which is v. impressive.
> >>
> >> I've improved my wrapper script (linux only sorry) to ignore
> >> -showversion and handle -Xbootclasspath/[ap] appropriately. I've
> >> attached this to HARMONY-583.
> >>
> >> I had to exclude two luni tests which were causing the vm to hang:
> >>
> >> tests/api/java/lang/IllegalThreadStateExceptionTest.java
> >> tests/api/java/lang/ThreadTest.java
> >>
> >> But the new test results are:
> >>
> >> Tests Failures Errors Success rate
> >> 8348 1295 892 73.80%
> >>
> >> which is progress even though the success rate went down.
> >>
> >> Many of the failures share the same root causes so I think this
> >> figure could improved pretty quickly.
> >>
> >> I wish there was a tool to summarise the root failures out of 2000+
> >> junit test reports! Just scanning at random, the most common errors
> >> seem to be:
> >>
> >> 1)
> >>
> >> not implemented
> >>
> >> java.lang.RuntimeException: not implemented at
> >> java.lang.ClassLoader.getResources(ClassLoader.java:224) at
> >> org.apache.harmony.jndi.internal.EnvironmentReader.readMultipleResourceFiles
> >>
> >> (EnvironmentReader.java:227) at
> >> org.apache.harmony.jndi.internal.EnvironmentReader$2.run
> >> (EnvironmentReader.java:280) at
> >> java.security.AccessController.doPrivileged
> >> (AccessController.java:241) at
> >> org.apache.harmony.jndi.internal.EnvironmentReader.readApplicationResourceFiles
> >>
> >> (EnvironmentReader.java:278) at javax.naming.InitialContext.internalInit
> >> (InitialContext.java:207) at javax.naming.InitialContext.<init>
> >> (InitialContext.java:151) at
> >> org.apache.harmony.jndi.tests.javax.naming.InitialContextMockTest.setUp
> >> (InitialContextMockTest.java:50)
> >>
> >> 2)
> >>
> >> not implemented
> >>
> >> java.lang.RuntimeException: not implemented at
> >> org.apache.harmony.kernel.vm.VM.getNonBootstrapClassLoader(VM.java:77) at
> >> java.io.ObjectInputStream.readObject(ObjectInputStream.java:1942) at
> >> java.io.ObjectInputStream.readObject(ObjectInputStream.java:1901) at
> >> javax.security.auth.SubjectTest.test_PrincipalSetInvalidSerForm
> >> (SubjectTest.java:1297) at java.lang.reflect.Method.invokeNative
> >> (Method.java) at org.apache.harmony.auth.internal.SecurityTest.runTest
> >> (SecurityTest.java:109)
> >>
> >> 3) Many of the crypto/auth/security tests are failing with
> >> "implementation
> >> not found" type errors.
> >>
> >> 4)
> >>
> >> META-INF/ALICE.SF has invalid digest for Test.class in /var/tmp/
> >> hyts_resources45209/TestCodeSigners.jar
> >>
> >> java.lang.SecurityException: META-INF/ALICE.SF has invalid digest for
> >> Test.class in /var/tmp/hyts_resources45209/TestCodeSigners.jar at
> >> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:331) at
> >> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:242) at
> >> java.util.jar.JarFile.getInputStream(JarFile.java:340) at
> >> org.apache.harmony.archive.tests.java.util.jar.JarEntryTest.test_getCodeSigners
> >>
> >> (JarEntryTest.java:122) at
> >> java.lang.reflect.Method.invokeNative(Method.java)
> >>
> >> Regards,
> >> Mark.
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Ivan
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Tim Ellison <t....@gmail.com>.
Ivan Volosyuk wrote:
> Yes, there are a lot of functions without implementation. I have
> inserted this exceptions there to fast detect this places. It will
> also be a few UnsatisfiedLinkErrors for some missing functions in
> java.lang.reflect.Array.
> Security is just no-op for now. I have almost zero knowledge in this area.
> Most probable reason for the hang in two luni tests is bug or
> unimplemented functionality in Thread.java
> One of problems in the Thread.java I have no clue how to solve is:
> Classlib implementation uses its own thread manager implementation,
> jchevm has also its own. Some classlib's native methods implementation
> rely on thread_attach() call before them, otherwise they crash. I have
> implemented this in VMThread.run(). But JNI ThreadAttach in jchevm
> doesn't call classlib's thread_attach(), so threads attached via JNI
> will crash classlib.
There are requirements on the VM in order to run the classlib native
code, like setting up the port library and playing nicely with the
thread library. For example, native's monitor operations require that
the thread has been attached via hythread_attach() [1].
I don't know the JCHEVM code well enough to point to the right place,
but performing an hythread_attach() when a JCHEVM thread is
created/attached -- and a matching detach -- would be the answer.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/hythread_8c.html?view=co
Regards,
Tim
> --
> Ivan
>
> On 6/8/06, Mark Hindess <ma...@googlemail.com> wrote:
>>
>> On 7 June 2006 at 20:50, "Mark Hindess" <ma...@googlemail.com>
>> wrote:
>> >
>> > With HARMONY-569, HARMONY-572 and a couple of simple hacks - like
>> > removing the -showversion jvm arguments from test runs - I've been
>> > able to run 63% of the classlib tests. I should get more running with
>> > a little more effort. The test results were:
>> >
>> > Tests Failures Errors Success rate
>> > 5601 360 744 80.29%
>> >
>> > which is v. impressive.
>>
>> I've improved my wrapper script (linux only sorry) to ignore
>> -showversion and handle -Xbootclasspath/[ap] appropriately. I've
>> attached this to HARMONY-583.
>>
>> I had to exclude two luni tests which were causing the vm to hang:
>>
>> tests/api/java/lang/IllegalThreadStateExceptionTest.java
>> tests/api/java/lang/ThreadTest.java
>>
>> But the new test results are:
>>
>> Tests Failures Errors Success rate
>> 8348 1295 892 73.80%
>>
>> which is progress even though the success rate went down.
>>
>> Many of the failures share the same root causes so I think this
>> figure could improved pretty quickly.
>>
>> I wish there was a tool to summarise the root failures out of 2000+
>> junit test reports! Just scanning at random, the most common errors
>> seem to be:
>>
>> 1)
>>
>> not implemented
>>
>> java.lang.RuntimeException: not implemented at
>> java.lang.ClassLoader.getResources(ClassLoader.java:224) at
>> org.apache.harmony.jndi.internal.EnvironmentReader.readMultipleResourceFiles
>>
>> (EnvironmentReader.java:227) at
>> org.apache.harmony.jndi.internal.EnvironmentReader$2.run
>> (EnvironmentReader.java:280) at
>> java.security.AccessController.doPrivileged
>> (AccessController.java:241) at
>> org.apache.harmony.jndi.internal.EnvironmentReader.readApplicationResourceFiles
>>
>> (EnvironmentReader.java:278) at javax.naming.InitialContext.internalInit
>> (InitialContext.java:207) at javax.naming.InitialContext.<init>
>> (InitialContext.java:151) at
>> org.apache.harmony.jndi.tests.javax.naming.InitialContextMockTest.setUp
>> (InitialContextMockTest.java:50)
>>
>> 2)
>>
>> not implemented
>>
>> java.lang.RuntimeException: not implemented at
>> org.apache.harmony.kernel.vm.VM.getNonBootstrapClassLoader(VM.java:77) at
>> java.io.ObjectInputStream.readObject(ObjectInputStream.java:1942) at
>> java.io.ObjectInputStream.readObject(ObjectInputStream.java:1901) at
>> javax.security.auth.SubjectTest.test_PrincipalSetInvalidSerForm
>> (SubjectTest.java:1297) at java.lang.reflect.Method.invokeNative
>> (Method.java) at org.apache.harmony.auth.internal.SecurityTest.runTest
>> (SecurityTest.java:109)
>>
>> 3) Many of the crypto/auth/security tests are failing with
>> "implementation
>> not found" type errors.
>>
>> 4)
>>
>> META-INF/ALICE.SF has invalid digest for Test.class in /var/tmp/
>> hyts_resources45209/TestCodeSigners.jar
>>
>> java.lang.SecurityException: META-INF/ALICE.SF has invalid digest for
>> Test.class in /var/tmp/hyts_resources45209/TestCodeSigners.jar at
>> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:331) at
>> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:242) at
>> java.util.jar.JarFile.getInputStream(JarFile.java:340) at
>> org.apache.harmony.archive.tests.java.util.jar.JarEntryTest.test_getCodeSigners
>>
>> (JarEntryTest.java:122) at
>> java.lang.reflect.Method.invokeNative(Method.java)
>>
>> Regards,
>> Mark.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [jchevm+classlibadapter] Running classlib tests
Posted by Ivan Volosyuk <iv...@gmail.com>.
Yes, there are a lot of functions without implementation. I have
inserted this exceptions there to fast detect this places. It will
also be a few UnsatisfiedLinkErrors for some missing functions in
java.lang.reflect.Array.
Security is just no-op for now. I have almost zero knowledge in this area.
Most probable reason for the hang in two luni tests is bug or
unimplemented functionality in Thread.java
One of problems in the Thread.java I have no clue how to solve is:
Classlib implementation uses its own thread manager implementation,
jchevm has also its own. Some classlib's native methods implementation
rely on thread_attach() call before them, otherwise they crash. I have
implemented this in VMThread.run(). But JNI ThreadAttach in jchevm
doesn't call classlib's thread_attach(), so threads attached via JNI
will crash classlib.
--
Ivan
On 6/8/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 7 June 2006 at 20:50, "Mark Hindess" <ma...@googlemail.com> wrote:
> >
> > With HARMONY-569, HARMONY-572 and a couple of simple hacks - like
> > removing the -showversion jvm arguments from test runs - I've been
> > able to run 63% of the classlib tests. I should get more running with
> > a little more effort. The test results were:
> >
> > Tests Failures Errors Success rate
> > 5601 360 744 80.29%
> >
> > which is v. impressive.
>
> I've improved my wrapper script (linux only sorry) to ignore
> -showversion and handle -Xbootclasspath/[ap] appropriately. I've
> attached this to HARMONY-583.
>
> I had to exclude two luni tests which were causing the vm to hang:
>
> tests/api/java/lang/IllegalThreadStateExceptionTest.java
> tests/api/java/lang/ThreadTest.java
>
> But the new test results are:
>
> Tests Failures Errors Success rate
> 8348 1295 892 73.80%
>
> which is progress even though the success rate went down.
>
> Many of the failures share the same root causes so I think this
> figure could improved pretty quickly.
>
> I wish there was a tool to summarise the root failures out of 2000+
> junit test reports! Just scanning at random, the most common errors
> seem to be:
>
> 1)
>
> not implemented
>
> java.lang.RuntimeException: not implemented at
> java.lang.ClassLoader.getResources(ClassLoader.java:224) at
> org.apache.harmony.jndi.internal.EnvironmentReader.readMultipleResourceFiles
> (EnvironmentReader.java:227) at
> org.apache.harmony.jndi.internal.EnvironmentReader$2.run
> (EnvironmentReader.java:280) at java.security.AccessController.doPrivileged
> (AccessController.java:241) at
> org.apache.harmony.jndi.internal.EnvironmentReader.readApplicationResourceFiles
> (EnvironmentReader.java:278) at javax.naming.InitialContext.internalInit
> (InitialContext.java:207) at javax.naming.InitialContext.<init>
> (InitialContext.java:151) at
> org.apache.harmony.jndi.tests.javax.naming.InitialContextMockTest.setUp
> (InitialContextMockTest.java:50)
>
> 2)
>
> not implemented
>
> java.lang.RuntimeException: not implemented at
> org.apache.harmony.kernel.vm.VM.getNonBootstrapClassLoader(VM.java:77) at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:1942) at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:1901) at
> javax.security.auth.SubjectTest.test_PrincipalSetInvalidSerForm
> (SubjectTest.java:1297) at java.lang.reflect.Method.invokeNative
> (Method.java) at org.apache.harmony.auth.internal.SecurityTest.runTest
> (SecurityTest.java:109)
>
> 3) Many of the crypto/auth/security tests are failing with "implementation
> not found" type errors.
>
> 4)
>
> META-INF/ALICE.SF has invalid digest for Test.class in /var/tmp/
> hyts_resources45209/TestCodeSigners.jar
>
> java.lang.SecurityException: META-INF/ALICE.SF has invalid digest for
> Test.class in /var/tmp/hyts_resources45209/TestCodeSigners.jar at
> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:331) at
> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:242) at
> java.util.jar.JarFile.getInputStream(JarFile.java:340) at
> org.apache.harmony.archive.tests.java.util.jar.JarEntryTest.test_getCodeSigners
> (JarEntryTest.java:122) at java.lang.reflect.Method.invokeNative(Method.java)
>
> Regards,
> Mark.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org