Re: Mauve Bytecode Verifier Testsuite

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Ranjit" == Ranjit Mathew <rmathew@hotmail.com> writes:

Ranjit>     Curiously, even JDK 1.4.2_03 on my Linux box fails
Ranjit> some verifier test cases:
Ranjit> FAIL: /usr/java/j2sdk1.4.2_03/bin/java exception.fail.depth

If this fails it is definitely a bug in the verifier.
In this case the method uses more stack space than was declared.
The verifier should reject this program.

I wonder if you could use this to construct a JVM-killing program.
It's possible you could overwrite a word on the stack.

Ranjit> FAIL: /usr/java/j2sdk1.4.2_03/bin/java exception.fail.uninit

This code violates an explicit constraint, namely that an
uninitialized reference cannot appear in a local variable in an
exception region.  The verifier must reject.

Ranjit> FAIL: /usr/java/j2sdk1.4.2_03/bin/java simple.fail.verify4

This has a non-static <clinit> method, which is probably invalid.
I don't recall if there is an explicit constraint against this.

Ranjit> FAIL: /usr/java/j2sdk1.4.2_03/bin/java subr.pass.mergeok

This one is a bit strange in that we have a jsr with no corresponding
ret.  I think Sun's verifier changed its mind on this test between 1.3
and 1.4.

Ranjit> FAIL: /usr/java/j2sdk1.4.2_03/bin/java subr.pass.noretend

This one is weird, it has a `jsr' as the last instruction.  This is
safe since there is no corresponding `ret'.  This is pathological, it
is probably fine for a verifier to either accept or reject this.
There are plenty of strange cases where it isn't clear what is the
appropriate result, bytecode verification isn't nearly well-defined
enough.

This case made at least one version of the JDK SEGV :-)
1.3.something, I think.

Ranjit> BTW, even in this limited testsuite the GCJ compiler
Ranjit> seems to fare far worse than the interpreter.

Yup.  Though your results look even worse than I recall.  Look at the
log files to make sure there isn't some systemic problem.

Tom