Test case failing:
nsk/stress/jck122/jck122007

Note: This testcase failing for a while , there were 8 bug reports most of them closed/integrated except one...which is NYI on kestrel.
 
Build:       1.4.1-beta-b04
Platform:    solx86
VM:          ServerVM
Mode:        mixed
HotSpot Version: 
Java HotSpot(TM) Client VM
 (build 20020308105420.jmasa.baseline-fastdebug1-debug,  mixed mode)


How to reproduce:
cd /net/jano.sfbay/export/disk20/GammaBase/Bugs/<bug-id>
sh doit.sh

******Running the test with Hopper-weekahead 
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b04)
Java HotSpot(TM) Server VM (build 20020308105420.jmasa.baseline-fastdebug-debug, mixed mode)
#
# HotSpot Virtual Machine Error, assertion failure
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Server VM (20020308105420.jmasa.baseline-fastdebug-debug mixed mode)
#
# assert(m->is_perm(), "bad methodOop in interpreter frame")
#
# Error ID: /net/balvenie.sfbay/export/imgr_home/ws/20020308105420.jmasa.baseline/src/share/vm/runtime/frame.cpp, 246
#
# Problematic Thread: prio=5 tid=0x81c34c8 nid=0x79 runnable 
#
Dumping core....
Abort
******Running the test with Hoper promoted build 
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b04)
Java HotSpot(TM) Server VM (build 1.4.1-beta-b04, mixed mode)

Unexpected Signal : 11 occurred at PC=0xDE8E4382
Function=JVM_FillInStackTrace+0x68A
Library=/net/koori.sfbay/p/v03/jdk/1.4.1/beta/b04/binaries/solx86/jre/lib/i386/server/libjvm.so

Current Java thread:
Segmentation Fault
******Running the test with Merlin promoted build 
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Server VM (build 1.4.0-b92, mixed mode)

Unexpected Signal : 11 occurred at PC=0xDE8E4054
Function=JVM_FillInStackTrace+0x61A
Library=/net/Koori.sfbay/a/v07/jdk/1.4/fcs/binaries/solx86/jre/lib/i386/server/libjvm.so

Current Java thread:
Segmentation Fault
nsk/stress/jck12a/jck12a005                                       compile_and_execute # 4652165 4697667 4787853 4866639
nsk/stress/jck12a/jck12a006                                       compile_and_execute # 4338880 4866639
nsk/stress/jck12a/jck12a007                                       compile_and_execute # 4694035 4866639
nsk/stress/jck12a/jck12a008                                       compile_and_execute # 4694035 4866639
nsk/stress/jck12a/jck12a009                                       compile_and_execute # 4652974
nsk/stress/jck12a/jck12a010                                       compile_and_execute # 4239045 4506500 4532518 4701435
nsk/stress/jck12a/jck12a011                                       compile_and_execute # 4311720 4338886 4506500 4532518 4866639
nsk/stress/jck12a/jck12a012                                       compile_and_execute # 4383861 4434628 4463818 4506500 4532518 4652640 4695869 4866639
nsk/stress/jck12a/jck12a013                                       compile_and_execute # 4475282 4506500 4651032 4694035 4760743 4787972
nsk/stress/jck12a/jck12a014                                       compile_and_execute # 4475282 4506500 4532518 4695869
nsk/stress/jck12a/jck12a015                                       compile_and_execute # 4501596 4651032
nsk/stress/jck12a/jck12a016                                       compile_and_execute # 4310295 4501596 4651032 4866639
nsk/stress/jck12a/jck12a017                                       compile_and_execute # 4501596 4506500 4532518 4641537 4866639 4870281
nsk/stress/memory/memleak001                                      compile_and_execute # 4245057
nsk/stress/memory/memleak003                                      compile_and_execute # 4245057
nsk/stress/memory/memleak004                                      compile_and_execute # 4245057 4245060 4400007
nsk/stress/network/network001                                     compile_and_execute # 4747484
nsk/stress/network/network003                                     compile_and_execute # 4418490 4747484
nsk/stress/network/network004                                     compile_and_execute # 4483207
nsk/stress/network/network005                                     compile_and_execute # 4747484
nsk/stress/network/network006                                     compile_and_execute # 4747484
nsk/stress/numeric/numeric001                                     compile_and_execute # 4489212
nsk/stress/numeric/numeric002                                     compile_and_execute # 4489212
nsk/stress/numeric/numeric003                                     compile_and_execute # 4489212
nsk/stress/numeric/numeric004                                     compile_and_execute # 4489212
nsk/stress/numeric/numeric005                                     compile_and_execute # 4489212
nsk/stress/numeric/numeric006                                     compile_and_execute # 4489212
nsk/stress/numeric/numeric007                                     compile_and_execute # 4489212
nsk/stress/numeric/numeric008                                     compile_and_execute # 4489212
nsk/stress/numeric/numeric009                                     compile_and_execute # 4489212
nsk/stress/numeric/numeric010                                     compile_and_execute # 4489212
nsk/stress/stack/b4502350                                         compile_and_execute # 4701978 4787972
nsk/stress/stack/b4525850                                         compile_and_execute # 4787990
nsk/stress/stack/b4732557                                         compile_and_execute # 4787990 4826555
nsk/stress/stack/stack001                                         compile_and_execute # 4463493 4697667 4787990
nsk/stress/stack/stack002                                         compile_and_execute # 4446390 4651836 4697667 4787990
nsk/stress/stack/stack003                                         compile_and_execute # 4497237 4787990 4900635
nsk/stress/stack/stack004                                         compile_and_execute # 4497237 4787990 4900635
nsk/stress/stack/stack005                                         compile_and_execute # 4497237 4787990 4900635
nsk/stress/stack/stack006                                         compile_and_execute # 4497237 4787990 4900635
nsk/stress/stack/stack007                                         compile_and_execute # 4787990
nsk/stress/stack/stack008                                         compile_and_execute # 4400208 4457254 4497237 4697667 4787990
nsk/stress/stack/stack009                                         compile_and_execute # 4497237 4787990 4900635
nsk/stress/stack/stack010                                         compile_and_execute # 4497237 4787990 4900635
nsk/stress/stack/stack011                                         compile_and_execute # 4497237 4787990 4900635
nsk/stress/stack/stack012                                         compile_and_execute # 4497237 4787990 4900635
nsk/stress/stack/stack013                                         compile_and_execute # 4497237 4787990 4900635
nsk/stress/stack/stack014                                         compile_and_execute # 4787990
nsk/stress/stack/stack015                                         compile_and_execute # 4468289 4787990
nsk/stress/stack/stack016                                         compile_and_execute # 4475282 4497237 4787990 4826555 4900635
nsk/stress/stack/stack017                                         compile_and_execute # 4446381 4475282 4787990
nsk/stress/stack/stack018                                         compile_and_execute # 4446381 4475282 4697667 4787990 4900635
nsk/stress/stack/stack019                                         compile_and_execute # 4497237 4787990
Posted Date : 2008-05-20 15:53:21.0

N/A

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

  xxxxx@xxxxx   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.

  xxxxx@xxxxx   2002-05-01

Fix checked in for mantis.

  xxxxx@xxxxx   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.


  xxxxx@xxxxx   2003-03-25