better error on VerifyError
Per Bothner
per@bothner.com
Tue Jan 15 13:18:00 GMT 2002
Compiling Kawa gave me a VerifyError, but it was very uninformative,
without specifying the class of the method.
I made a partial patch to improve the situation, for the particular
error I experience, and I now get:
Exception in thread "main" java.lang.VerifyError: verification failed at
PC 3 in gnu.xquery.lang.XQuery:getFormat: incompatible return type
at 0x40248970: java.lang.Throwable.Throwable(java.lang.String)
(/home/bothner/GNU/install-gcc/lib/libgcj.so.2)
Before checking it in, I'd like to get some feedback (especially from
Tom, of course) on how we want to do this more generally.
The basic problem is that we need to pass the verifier state, or at
least the current method, to the verify_fail routine. However,
most calls to verify_fail are in either static methods, or in methods
of the inner classes type or state. One solution is to make all
the methods non-static, and to add a field to type that points back
to the _Jv_ByteCodeVerifier object. The alternative is to explicitly
pass _Jv_ByteCodeVerifier in method calls. The tradoff is an extra
for each each type and state object vs an extra parameter in each
method call. I lean towards the latter. The former probably
requires fewer changes; however, however, it is easier to make the
fixes on an incremental bases with the latter. For example,
type::set_uninitalized becomes:
void set_uninitialized (int npc,
_Jv_ByteCodeVerifier* verifier=NULL)
{
... verify_fail("...", verifier);
}
Then we can incrementally fix the callers of set_uninitialized to
pass the verifier reference, and so on.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: verify.patch
URL: <http://gcc.gnu.org/pipermail/java/attachments/20020115/55dbd75a/attachment.ksh>
More information about the Java
mailing list