Date: Thu, 4 Sep 1997 11:26:47 -0700
From: Frank Yellin <###@###.###>
To: never@pan, david.bowen@pan
CC: dlong@pan
Subject: Bug in executeJava_p5.inc


Dave and Tom:

We've found a bug in executeJava_p5.inc, part of the assembly loop for the
x86.

The end of the code after the label Lb(ivqw_not_ijn) needs to be as follows:


xor eax,eax
xor edx,edx
MOV(eax,al,BYTE PTR [esi+3])

MOV(edx,dl, BYTE PTR [ecx + ee_exceptionKind]) ;exception?
mov DWORD PTR [ebx + javaframe_optop], edi
test edx,edx
jnz Lb(N0_ivq_invoker_error)
   add esi,3 ;esi=frame->returnpc
   Dispatch0

Note that that line "add esi,3" has been moved until after it has been
determined that the method call finished without any errors. As a side
effect, we needed to change
MOV(eax,al,BYTE PTR [esi])
to be
MOV(eax,al,BYTE PTR [esi+3])

Ignore the fact that in ur copy of the code, the antepenultimate line is
jnz Lb(N0_ivq_invoker_error) a zero
while yours has
jnz Lb(NO_ivq_invoker_error) a capital o
This is a historical bogon that should eventually be fixed. (I think zero
goes better with N1 and N2, rather than the word "no")

Not fixing this bug causes an assertion failure when running a debugged
version of the code. One test in the JCK kills a process when it is in
the middle of calling sink.notifyAll() in the following code.

    public synchronized void flush() throws IOException {
if (sink != null) {
            synchronized (sink) {
                sink.notifyAll();
            }
}
    }

The process notices the exception, but because it's PC (esi) has already
been incremented, it thinks it is outside the range of the "synchronized".
The lock is never released.

== Frank

john.bui@eng 1997-10-17

No specific test case available. Implicity tested, verified with exposure.