interpreter question, darwin libffi

Andrew Haley aph@redhat.com
Sun Feb 2 15:02:00 GMT 2003


Andreas Tobler writes:
 > Hi,
 > 
 > I'm still trying to investigate the InvokeReturn failure on libgcj darwin.
 > The native InvokeReturn passes but the interpreted one fails with a bus 
 > error when I come to pass the long or double result.
 > 
 > I tracked down the situation to a point where the POPL in interpret.cc 
 > overwrites my stackpointer from libffi. Coming back into libffi I can't 
 > return since I don't know where I was.
 > 
 > Now I don't understand the interpret.cc part enough to say whether it is 
 > a bug in libffi or in the interpreter.
 > 
 > In interpret.cc my POPL definition is this one:
 > # define POPL()    ({ _Jv_word2 w2; \
 >                       w2.ia[1] = (--sp)->ia[0]; \
 >                       w2.ia[0] = (--sp)->ia[0]; w2.l; })
 > 
 > My SIZEOF_VOID_P is 4 long.
 > 
 > In _Jv_InterpMethod::run I don't see where my stack is coming from.
 > 
 > It would be great to get some clarification here, as I don't know which 
 > direction I should continue investigating.

The stack pointer is initialized with max_stack words here:

  _Jv_word stack[max_stack];

This is a variable size array, a gcc extension.

  _Jv_word *sp = stack;

Note that sp is the very first fixed size local variable
in_Jv_InterpMethod::run, so it is probably allocated the stack slot
immediately next to the saved stack pointer or program counter.

Perhaps sp is saved on the stack at an offset from the frame pointer.
Then a call is made.  When the call resturns, the frame pointer is not
restored correctly, so when POPL is executed the wrong stack slot is
overwritten.  All you have to do to check this theory is print
__builtin_frame_address(0) before and after ffi_java_raw_call().


It's possible that it's not the frame pointer that is being corrupted,
but some other register.  

1: x/i $pc  0x43e94 <_ZN16_Jv_InterpMethod3runEPvP7ffi_raw+9476>:	stw r10,4(r13)

This is writing to a double word memory location that is passed from
the caller.  Perhaps the caller didn't allocate enough space or
perhaps the register or memory slot that cotains retp has been
corrupted.

To see if this is true, check retp when _Jv_InterpMethod::run is
entered and again when your PC is overwritten.

Andrew.



More information about the Java mailing list