JDK-6983989 : JVM native socket code uses too much of the stack
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6u14
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2010-09-10
  • Updated: 2011-07-07
  • Resolved: 2010-12-16
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.
JDK 6
6-poolResolved
Related Reports
Relates :  
JDK-6983892 - nsk.stress.stack.stack008.stack008 crashes starting JDK7 b108
Relates :  
JDK-7079763 - Shouldn't socketoutputstream_socketwrite throw a stackoverflowexception?
Relates :  
JDK-6983240 - guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong
Description
A recursion bug in the customer's code caused most of a thread's stack to be consumed.
At the end of the recursion, the code stepped into a jvm native call to socketWrite.
While in native code, the stack was exhausted which resulted in a SIGSEGV.

They had not set a value for StackShadowPages and the default value was 3.
This bug is being created to investigate why a value of 3 was not enough to prevent the 
stack overflow on the native side.

Here is the end of the stack after the recursion has stopped.

Java Stack Trace for SIRootCache-790400429
Thread state = IN_VM
 - private native void socketWrite0(java.io.FileDescriptor, byte[], int, int) @0xfffffffec07f7dd8 @bci = 0, pc = 0xffffffff7830d08c (Compiled; informat
 - private void socketWrite(byte[], int, int) @0xfffffffec07f7f78 @bci = 44, line = 92, pc = 0xffffffff78345f28 (Compiled)
 - public void write(byte[], int, int) @0xfffffffec07f81f0 @bci = 4, line = 136, pc = 0xffffffff78345f28 (Compiled)
 - protected void send(int) @0xfffffffec2da30b0 @bci = 60, pc = 0xffffffff7833e510 (Compiled)
 - public void flush() @0xfffffffec2d88220 @bci = 15, pc = 0xffffffff7833e510 (Compiled)
 - protected void getNextPacket() @0xfffffffec2d89eb8 @bci = 41, pc = 0xffffffff7833e510 (Compiled)
 - public int read(byte[], int, int) @0xfffffffec2d89c90 @bci = 33, pc = 0xffffffff7830d610 (Compiled)
 - public int read(byte[]) @0xfffffffec2d89b58 @bci = 5, pc = 0xffffffff7830d610 (Compiled)
 - public int read() @0xfffffffec2d89a88 @bci = 5, pc = 0xffffffff7830d610 (Compiled)
 - short unmarshalUB1() @0xfffffffec2dcec88 @bci = 6, line = 1104, pc = 0xffffffff7830d610 (Compiled)
 - byte unmarshalSB1() @0xfffffffec2dceb70 @bci = 1, line = 1075, pc = 0xffffffff7831fd7c (Compiled)
 - void receive() @0xfffffffec2e17ef0 @bci = 52, line = 480, pc = 0xffffffff7831fd7c (Compiled)
 - void doOall8(boolean, boolean, boolean, boolean) @0xfffffffec2d06120 @bci = 649, line = 219, pc = 0xffffffff784b340c (Compiled)
 - void executeForDescribe() @0xfffffffec2d071a8 @bci = 39, line = 813, pc = 0xffffffff788c5138 (Compiled)
 - void executeMaybeDescribe() @0xfffffffec2cf01d8 @bci = 102, line = 1049, pc = 0xffffffff788c5138 (Compiled)
 - void executeMaybeDescribe() @0xfffffffec2d07398 @bci = 11, line = 854, pc = 0xffffffff7875a690 (Compiled)
 - void doExecuteWithTimeout() @0xfffffffec2cf0568 @bci = 132, line = 1154, pc = 0xffffffff7883edec (Compiled)
 - int executeInternal() @0xfffffffec2cd6380 @bci = 94, line = 3370, pc = 0xffffffff788390a8 (Compiled)
 - public java.sql.ResultSet executeQuery() @0xfffffffec2cd6528 @bci = 17, line = 3415, pc = 0xffffffff78846f48 (Compiled)
 - public java.sql.ResultSet executeQuery() @0xfffffffec308e270 @bci = 9, line = 78, pc = 0xffffffff788db198 (Compiled)
 - public java.sql.ResultSet executeQuery() @0xfffffffec308ced8 @bci = 1, line = 64, pc = 0xffffffff788db198 (Compiled)
 - public java.sql.ResultSet executeQuery() @0xfffffffec3025a60 @bci = 12, line = 224, pc = 0xffffffff788db198 (Compiled)
 - public java.lang.Object[] startResultSet(mks.im.core.sql.SQLStatement$Sql, java.lang.Object[]) @0xfffffffec44f89e0 @bci = 114, line = 397, pc = 0xff
 - public mks.im.core.sql.QueryResult startQueryResult(mks.im.core.sql.RepoStatement  ...   <---**  start of recursive pattern
Comments
EVALUATION Changes of default socketWrite thread-local buffer size in 6u14 provoke this problem as this buffer is larger than default stack guard. Users have to use -XX:StackShadowPages=10 if they fals into this problem but it requres a fix for 6983240.
18-10-2010
PUBLIC COMMENTS Note that a StackOverflowError will only be thrown if the SEGV occurs in the yellow-zone _and_ the thread is executing Java code. If the overflow occurs when the Java code has called into the VM or into other native code then it is a fatal and unrecoverable error.
13-09-2010