EVALUATION
This failure involves stack overflow. The root cause hasn't been determined yet,
but at the point where the fatal VM error is reported a non-interpreter frame h
as been treated as if it belonged to the interpreter and this basic mistake duri
ng the attempt to unwind the stack and report the stack overflow results in a se
gment fault. Run with assertions, the following is reported:
assert(m->is_perm(), "bad methodOop in interpreter frame")
The mystery to solve is why it appears that control simply must have reached the
part of JVM_handle_solaris_signal that detects a SIGSEGV that is not to do with
a null pointer check (that is, one that is a genunine bad memory reference) yet
dbx never gets to a breakpoint in this part of this function.
However at this point it appears certain that this is a valid bug.
I've added an attachment with all the QA test classes required to run this progr
am as well as a script suitable for use inside a Hotspot workspace "debug" direc
tory (with just a touch of pathname editing).
Also included as an attachment the needed jck122007.class
###@###.### 2002-04-23
On x86 we explicitly check for stack overflow before pushing zeros to zero
the locals. This is because if there is an incursion into the yellow or red
stack zones, the stack pointer will already be too low to push a call to
the signal handler on. So there's an explicit check in the interpreter.
In this case, the frame with the 65K locals is the topmost interpreter frame,
whereas in other cases it was called from a valid interpreter frame. This case
sees an error because the explicit stack check happens before the interpreter
frame is pushed. The code to create and throw the exception assume that there's
valid stuff in the interpreter frame, including the previous stack pointer and
methodOop. Which causes all sorts of bad things to happen.
I have a fix for this which is simple, push a small dummy interpreter frame
on at the point of stack overflow. This also resolves the problem
observed in 7/22/99 for this, which is essentially for the same testcase.
I need to get this fix discussed and reviewed.
###@###.### 2002-05-01
Fix checked in for mantis.
###@###.### 2002-06-24
Additional fixes for -server -Xint:
4652165 jck stress test crashing VM (partial)
This bug was still broken on sparc when tested with -Xss256k. The bug
is caused when the first interpreter frame after call_stub gets
a stack overflow error from a large number of local parameters. The
On i486 and ia64, a dummy interpreter frame is already pushed on the stack
so that the exception is handled in the interpreter. On sparc, the
exception pc is still in the generated assembly code for call_stub, which
stubGenerator_sparc.cpp generate_handler_for_implicit_exception() doesn't
know how to skip the call_stub frame and would get:
__ stop("wrong implicit exception");
Rather than add this case to the assembly code, add in the
frame size to the JavaCalls::call_helper() stack size call to
os::stack_shadow_pages_available() to check for the topmost frame.
###@###.### 2003-03-25
|
Java