From: Godmar Back (gback@cs.utah.edu)
Date: Wed Sep 09 1998 - 13:37:08 EDT
As the example below shows, we must prevent the verifier from
throwing a NoSuchFieldException (or any exception, for that matter)
while it assumes it cannot be reentered.
I suggest we ensure that all methods invoked by the verifier
fail instead of throwing exceptions. It is the caller's responsibility
to ensure that the failure is recognized and that an exception is
thrown when it is safe to do so.
I believe we can introduce these fixes gradually.
Let's look at two examples: getField and getMethodSignatureClass.
Both can be called from verifyBasicBlock and from kaffe.def.
In the latter case, they're invoked through #define's in the
engine/machine.h files. In the former case, they should not
throw an exception. In the latter case, they should: but once
we've changed them to fail, this can easily be accomplished in
these macros.
We should agree on some error propagation mechanism. In most cases,
at least two words must be propagated back: the type and the message
of an exception, for instance. We could use an "struct error" as
a return value. We could also "post" a pending exception in the
context of the running thread, as a thread-local variable. Of course,
we can't construct the exception before we actually throw it.
I should mention that Tim and I discussed another very similar problem
before. The other problem concern the fact that if an exception is
thrown while the VM takes a lock, this lock is not unlocked, hence
preventing other threads from forever entering that piece of code
(example: processClass and the static lock it takes)
Tim at this point argued that it might be sufficient to keep track
of the locks a threads holds, and unlock those if an exception is
thrown, essentially cleaning up after that thread.
However, in the case of verifyMethod/verifyBasicBlock, it appears
that simply releasing a lock might not be sufficient: tidyVerifyMethod
must be called as well. Of course, it might be possible to implement
a scheme where threads register "clean-up handlers" before entering
a block of code in which they could throw an exception. These
clean-up handlers could then unlock locks or perform other cleanup,
such as tidyVerifyMethod. In essence, this would amount to try/catch
blocks in C.
Another alternative, which would work with Tim's idea of keeping track
of locks and unlocking them if necessary, is to require all code to be
able to deal with exceptions. That would mean that all code would have
to be reentrant. Currently, this is not the case.
What do you think?
- Godmar
Forwarded message:
> From kaffe@rufus.w3.org Wed Sep 9 11:03:42 1998
> Resent-From: kaffe@rufus.w3.org
> Resent-Date: Wed, 9 Sep 1998 13:02:54 -0400
> Resent-Message-Id: <199809091702.NAA00044@rufus.w3.org>
> X-Authentication-Warning: rufus.w3.org: majordom set sender to owner-kaffe@rufus.w3.org using -f
> Date: Wed, 9 Sep 1998 13:02:54 -0400 (EDT)
> From: Mark Glemboski <markg@ans.net>
> Message-Id: <199809091702.NAA13995@gumby.ny.ans.net>
> To: kaffe@rufus.w3.org
> Subject: Re: Kaffe and OB - weird error
> X-Sun-Charset: ISO-8859-1
> Sender: owner-kaffe@rufus.w3.org
> Precedence: bulk
> Reply-To: kaffe@rufus.w3.org
> Errors-To: kaffe-error@rufus.w3.org
> X-loop: kaffe@rufus.w3.org
> X-mailing-list: kaffe@rufus.w3.org
>
> > > Hi,
> > >
> > > when trying to use ORBacus (formerly OmniBroker) with Kaffe, I get the
> > > following weird error :
> > >
> > > Kaffe: code-analyse.c:98: verifyMethod: Assertion `codeInfo == 0 && "
> > > Attempt to reenter verifier!"' failed.
> > >
> ...
> > It means what it says, namely that an attempt was made to reenter the
> > verifier. The verifier is a piece of single-threaded, non-reentrant
> > code.
> >
> > If the failure is reproducible, you could build a staticlib/intrp
> > version of kaffe and use gdb to produce a stacktrace. This should
> > give you some information what sequence of events led to this.
> > For instance, it could be that an exception is thrown while a
> > method was verified. The exception class is loaded, its methods
> > are verified, and voila. Obviously, this is wrong. We need to think
> > about it some more.
> >
> > - Godmar
> >
>
> I've encountered the same problem using ORBacus - your speculation
> sounds correct - here's the stack trace, but it's dynamiclib/jit -
> using 9/8 cvs tree on BSDI 4.0.
>
> mark
> Mark Glemboski
> ANS Communications
> 914-701-5026
> markg@ans.net
>
>
> #0 0xc0b3bd5 in kill ()
> #1 0xc0ff721 in abort ()
> #2 0xc0bfc7c in auth_check ()
> #3 0xc06349c in verifyMethod (meth=0x877e738) at code-analyse.c:97
> #4 0xc07e3ef in translate (meth=0x877e738) at ./jit/machine.c:201
> #5 0xc0620a7 in soft_fixup_trampoline (_pmeth=0x877e8b6) at soft.c:441
> #6 0xc0796a1 in i386_dft1 () at jit.def:1443
> #7 0xc061110 in execute_java_constructor_v (
> cname=0xc084497 "java.lang.NoSuchFieldError", cc=0x0,
> signature=0xc08445f "(Ljava/lang/String;)V",
> argptr=0x8046c48 "àÇz\bÔÓr\b\020") at support.c:175
> #8 0xc061142 in execute_java_constructor (
> cname=0xc084497 "java.lang.NoSuchFieldError", cc=0x0,
> signature=0xc08445f "(Ljava/lang/String;)V") at support.c:187
> #9 0xc059d18 in getField (idx=31, this=0x87256d8, isStatic=false,
> ret=0x8046d38) at lookup.c:180
> #10 0xc066a6e in verifyBasicBlock (meth=0x872e958, pc=94) at code-analyse.c:1416
> #11 0xc064d32 in verifyMethod (meth=0x872e958) at code-analyse.c:311
> #12 0xc07e3ef in translate (meth=0x872e958) at ./jit/machine.c:201
> #13 0xc0620a7 in soft_fixup_trampoline (_pmeth=0x8730134) at soft.c:441
> #14 0xc0796a1 in i386_dft1 () at jit.def:1443
> #15 0x876b55d in ?? ()
> #16 0x8768deb in ?? ()
> #17 0x8762483 in ?? ()
> #18 0x8641dc0 in ?? ()
> #19 0xc061798 in callMethodV (meth=0x804ee58, func=0x83ffab8, obj=0x0,
> args=0x8047520 "\001", ret=0x8047474) at support.c:512
> #20 0xc06f3dd in Kaffe_CallStaticVoidMethodV (env=0xc087520, cls=0x83bc818,
> meth=0x804ee58, args=0x804751c "\020oM\b\001") at jni.c:2251
> #21 0xc06f446 in Kaffe_CallStaticVoidMethod (env=0xc087520, cls=0x83bc818,
> meth=0x804ee58) at jni.c:2264
> #22 0x8048838 in main2 (env=0xc087520, argv=0x8047990, farg=2, argc=0)
> at main.c:188
> #23 0x8048716 in main (argc=2, argv=0x8047990) at main.c:108
> #24 0x8048624 in __start ()
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:56 EDT