JDK-4245436 : 1.3c1: IE5 on NT system crashes when running vm/instr/astore_w/astore_w004/astor
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_95,windows_nt
  • CPU: x86
  • Submitted: 1999-06-10
  • Updated: 1999-10-21
  • Resolved: 1999-10-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.0 kestrelFixed
Related Reports
Duplicate :  
JDK-4256603 - method with large number of locals causes StackOverflowError
Duplicate :  
JDK-4256091 - kestrel L fails: vm\instr\astore_w\astore_w004\astore_w00401 on win32 only
Relates :  
JDK-4277282 - Rare stack overflow problem (incorrect implementation)
Relates :  
JDK-4294942 - method with many locals crashes HotSpot in compiled mode
Description
IE5 on NT system will crash when when running the JCK test  vm/instr/astore_w/astore_w004/astore_w0041 (trusted and untrused) if using
hotspot.  Note that this test will pass if not using hotspot (using the jvm
at classic)

For test result, please view:
/net/sqesvr/plugin2/jck/results/kestrel/build_G/NT-IE5/vm/instr/astore_w/astore_w004/astore_w00401/astore_w00401.jtr
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kestrel-beta FIXED IN: kestrel-beta INTEGRATED IN: kestrel VERIFIED IN: kestrel
14-06-2004
EVALUATION Moe: Is 4244976 a dublicate of this one? This seems to more specific. If so, please close 4244976 as a dublicate. rene.schmidt@eng 1999-06-10 Vince, would you try this one out with build H of hotspot on build G of Kestrel? I tried and it seems to work. Let me know if you have problems. Thanks very much Moe Rene, See GammaBase/Bugs/<bugid> for the shell script to do this. The bug happens in: MethodOop.cpp 196. It just that IE does not get out gracefully. Now, you can fix it in 5 minutes. Which is what it should have taken if I just had tried to reproduce it. mohammad.gharahgouzloo@Eng 1999-07-19 I looked at the bug - method main calls one method (run) which has 2 parameters and 65535 locals, and run does a store into local number 65534. On 1.2.2 this all works fine. On 1.3 the default thread stack size was reduced from 1MB to 256K, so I get Y:\Bugs\4245436>java -Xint astore_w00401 Exception in thread "main" java.lang.StackOverflowError at astore_w00401.main(astore_w00401.jas This is also ok, but in debug mode I get: Y:\Bugs\4245436>java_g -Xint astore_w00401 # # HotSpot Virtual Machine Error, assertion failure # # assert(is_native() && bcp == code_base() || contains(bcp), "bcp doesn't belong to this method") # # Error ID: w:\src\share\vm\oops\methodOop.cpp, 196 # Should the interpreter do different stack banging for large frames so it makes sure to touch each 4Kb OS frame in order (like we do for compiled code?). steffen.grarup@eng 1999-07-20 ------------------------------ The problem in debug mode is that register esi should contain the bcp when the stack overflow happens but it doesn't - and in optimized mode it only worked accidentally. Fixed this problem. In any case, this bug exhibited 2 other problems w/ stack overflow that so far never happened; but that could happen. The current implementation is wrong if the stack overflow happens before the current frame is completely setup and the previous frame is not an interpreted frame. For now we don't have a good solution. robert.griesemer@Eng 1999-07-22 Note: The test creates a stack frame w/ 65534 locals a 4bytes each. Thus, this stack frame a few other frames add up to 256K which is the new stack size => stack overflow error. In classic this doesn't happen, I assume because the locals are kept in a heap allocated data structure? In any case, the stack over- flow behaviour is correct for this program running under HotSpot. robert.griesemer@Eng 1999-07-22
22-07-1999