Mauve Bytecode Verifier Testsuite

Wed Apr 7 20:17:00 GMT 2004

>>>>> "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