Mikhail Loenko wrote:
Hi!
If you are talking about this peace of code:
#ifndef _NDEBUG
vf_recompute_stackmaptable(method, &context6.substitution,
error, classwide.class_constraints);
result = context6.verify_method(method);
if (result != VF_OK) {
vf_create_error_message(method, context6, error);
}
tc_free(context6.substitution);
context6.substitution = NULL;
#endif
Yes, that's the piece of code.
then it should not be executed. it was written for debugging purposes
when I developed recompute stack map functionality.
(recompute stack map functionality populates modified on the fly class
file with correct stack map attributes)
This peace of code fails when original class file has 6.0 version
while it can't be verified with Java6 rules.
Just comment it out or even remove it.
Brilliant, thanks Mikhail! Ill remove that block altogether.
Regards,
Oliver
Thanks,
Mikhail
2009/9/4 Oliver Deakin <[email protected]>:
Alexey Varlamov wrote:
The changes that went into JSR202 include:
- split verifier support
- increase various size limits
- adding support for class literals
- minor changes to support Java language changes
I'm assuming that the problem in DRLVM is the loading on class literals.
Actually the class literals were incorporated in Java 5 (v49.0), as
well as other minor features for language support. AFAIK there are no
Java language changes between Java 5 and 6.
DRLVM does support these features, so the evil should be somewhere else.
Hi Alexey,
I have replied about this issue in another part of this thread [1]. It seems
there is a problem with some code intended for debug in the verifier. After
the initial java 6 method verify, the debug code then tries to recompute the
stack map table (which only seems to include Java 5 references oddly) and
then verify the method again, and this is where we fail. Without the debug
code in place the verification completes successfully.
Any ideas why the failure is occurring or why we would want to do the second
verify in debug mode after recomputing the stack map table?
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/harmony-dev/200909.mbox/%[email protected]%3e
[snip]
I'm happy to keep testing, and if we can make progress quickly then
let's press ahead, but otherwise let's open all the code and give the
6.0 stream a bit more attention before attempting the 6.0M1 again.
Right decision is already taken ;)
--
Regards,
Alexey
Regards,
Tim
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
