Bytecode verifiers

Bytecode verifiers

[Bernard Serpette]

                 Hello,

        Sorry to disturb you, I have a short question which I hope you
have the answer or at least a pointer to right person.. We are implementing
a bytecode verifier and we are searching for a collection of classfiles
in order to test the correctness of our implementation. We are particulary
interested by "dirty" classfiles (which can be generated by a correct
compiler) and "tricky" classfile (generated by optimizer or by hand).

	In the Mauve libraries, dirty classfiles will be a good suite in
order to test when "Class.forName" must raises an exception...

	So, do you know where we can find this kind of datas ? We still
don't have answers from JCK... By the way, we will happy to contribute
to Mauve project by providing our local dirty classfiles.

	Thanks in advance,

Bernard

Re: Bytecode verifiers

[Peter Naulls]

In message < 200012201108.eBKB8b402577@kevin.inria.fr >
          Bernard Serpette <Bernard.Serpette@sophia.inria.fr> wrote:

>         Sorry to disturb you, I have a short question which I hope you
> have the answer or at least a pointer to right person.. We are implementing
> a bytecode verifier and we are searching for a collection of classfiles
> in order to test the correctness of our implementation. We are particulary
> interested by "dirty" classfiles (which can be generated by a correct
> compiler) and "tricky" classfile (generated by optimizer or by hand).
> 
> 	In the Mauve libraries, dirty classfiles will be a good suite in
> order to test when "Class.forName" must raises an exception...
> 
> 	So, do you know where we can find this kind of datas ? We still
> don't have answers from JCK... By the way, we will happy to contribute
> to Mauve project by providing our local dirty classfiles.

First of all, I'd be very happy to see such tests in Mauve, as I use it
quite a bit to test my JVM.

It's not entirely clear what you're asking here (to me at least) - you
say you've got some dirty classes, but you also want some more classes?

One of the problems here is that Mauve is really only a test of the
library implementation - it doesn't (but perhaps should) target weak
spots in JVMs; it's not really organised in a manner suitable for this
- the tests are arranged in terms of library functionality, not JVM
functionality.

Peter


-- 
------------------------------------------------------------------------
 Peter Naulls - peter@erble.freeserve.co.uk
 Homepage - http://free.prohosting.com/~chocky/
 Java for RISC OS and ARM - http://free.prohosting.com/~chocky/java/
 Debian Linux on RiscPCs - http://www.erble.freeserve.co.uk/
------------------------------------------------------------------------

Re: Bytecode verifiers

[Tom Tromey]

>>>>> "Peter" == Peter Naulls <peter@erble.freeserve.co.uk> writes:

Peter> One of the problems here is that Mauve is really only a test of
Peter> the library implementation - it doesn't (but perhaps should)
Peter> target weak spots in JVMs; it's not really organised in a
Peter> manner suitable for this - the tests are arranged in terms of
Peter> library functionality, not JVM functionality.

For the completeness issue the only thing to do is for people to write
more tests.  Feel free to contribute!

For JVM tests, we could easily add a new directory for these.  We
could even add an entirely new test harness just for JVM tests, if
that is necessary.  We aren't overly constrained by the current way of
doing things.  Contributions welcome...

Tom

Re: Bytecode verifiers

[Peter Naulls]

In message < 877l4vynkr.fsf@creche.redhat.com >
          Tom Tromey <tromey@redhat.com> wrote:

> >>>>> "Peter" == Peter Naulls <peter@erble.freeserve.co.uk> writes:

> Peter> target weak spots in JVMs; it's not really organised in a
> Peter> manner suitable for this - the tests are arranged in terms of
> Peter> library functionality, not JVM functionality.
> 
> For the completeness issue the only thing to do is for people to write
> more tests.  Feel free to contribute!
> 
> For JVM tests, we could easily add a new directory for these.  We
> could even add an entirely new test harness just for JVM tests, if
> that is necessary.  We aren't overly constrained by the current way of
> doing things.  Contributions welcome...

Of course, you are right.  Unfortunately, last time I suggest
contributing stuff to mauve - I wrote a "FullTestHarness" some time ago,
which is all Java - I was met with apathy :-(   And in the next couple
of days I'll be laying my dirty paws on the JCK so I'm not sure if any
tests written after that would be in the best interests (I'm also under
commercial constraints, but my Employer would be open to negotiation).
I am still happy, however, to comment on the suitability and
organisation of such tests added - and certainly still use it.

Peter

-- 
------------------------------------------------------------------------
 Peter Naulls - peter@erble.freeserve.co.uk
 Homepage - http://free.prohosting.com/~chocky/
 Java for RISC OS and ARM - http://free.prohosting.com/~chocky/java/
 Debian Linux on RiscPCs - http://www.erble.freeserve.co.uk/
------------------------------------------------------------------------

tests that pass but indicate an error?

[Brian Jones]

So I've executed mauve against japhar+classpath with a given key file
(that eliminates things that blow up) and one strange thing I've
noticed is a set of tests that indicate they "PASS" although the
-verbose message indicates "Error."  Examples included below.

PASS: gnu.testlet.java.lang.Byte.ByteTest: Error: test_Basics failed - 1 (number 1)
PASS: gnu.testlet.java.lang.Byte.ByteTest: Error: test_Basics failed - 2 (number 1)
PASS: gnu.testlet.java.lang.Byte.ByteTest: Error: test_Basics failed - 3 (number 1)

-- 
Brian Jones <cbj@gnu.org>

Re: tests that pass but indicate an error?

[Tom Tromey]

Brian> So I've executed mauve against japhar+classpath with a given key file
Brian> (that eliminates things that blow up) and one strange thing I've
Brian> noticed is a set of tests that indicate they "PASS" although the
Brian> -verbose message indicates "Error."  Examples included below.

Some of the Mauve tests were auto-converted from a different test
suite.  The messages weren't fully changed from failure notices to
checkpoint names.  Lame, I agree...

Tom