JDK-4349646 : JNI EXCEPTION_STACK_OVERFLOW outside the VM
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_nt,windows_2000
  • CPU: x86
  • Submitted: 2000-06-29
  • Updated: 2012-11-02
  • Resolved: 2001-02-16
Related Reports
Relates :  
JDK-4362291 - Stack size argument ignored (-Xss and -ss)
Description

Name: rlT66838			Date: 06/29/2000


Y:\>java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

System.loadLibrary("dbService"); //c++ dll

...code preparing StringBuffer strParms

executeC(strParms.toString());

//a message shows up and crashed
# An EXCEPTION_STACK_OVERFLOW exception has been detected in native code
outside the VM.

executeC(char*) is within deService.dll.  If it were small, the program ran
fine.  But when it does the real work, e.g. fetching data from db, it crashes
before returning to Java.  The same dll works fine within VB/COM or C++ which
weid like to move away.  My NT has plenty memory when it occurs.  Is there
anyway to increase the stack by setting or configuration?

It's impossible to mail my dbService.dll as
well as its co-dll's for you to create the bug, since
they are all large binary legacy code, need db's and
other company environment to reach the break point.  

The confusion is that problem wouldn't occur if the
JNI function were light/small.  It won't overflow
under C++/VB/COM either.  It seems an invisible limit
is imposed when called by Java JNI.  It may be just
some unpopular setting or configuration.  It'll be
very helpful if you can point that out.

I'm not sure whether it's a bug or not.  I searched
Sun's JDC threads and found the same questions without
answers.  I also found similar cases listed as Bug in
Progress. 
(Review ID: 106426) 
======================================================================
Comments
EVALUATION john.coomes@eng 2001-02-15 The default stack size on windows programs is set at link time and written into the .exe file; java.exe has a default stack size of 256k. The Visual C++ tools dumpbin.exe and editbin.exe can be used to view/change the default value: c:\> dumpbin /all java.exe # look for 'stack reserve' # (the value is in hex) c:\> editbin /stack:0x60000 java.exe # set stack size to 384k Alternatively, the stack size for threads *other than the main thread* can also be set using the command line argument -Xss<size>, e.g., java -Xss1024k myprogram ... The -Xss option is not documented for jdk1.3 on windows, but is accepted; the option is documented on the jdk1.3 solaris pages. Note that -Xss cannot be used to change the main thread stack size because that is set by Windows at program startup; it can only be changed with the editbin.exe utility above. If -Xss<size> is used, the <size> is passed to the Windows beginthreadex function to set the stack size. However, at least on NT4.0 SP6, the o/s rounds up the stack size allocated for the new thread using very coarse granularity: if <size> is at least 1k less than the default stack size, the stack size is rounded up to the default; otherwise, the stack size is rounded up to a multiple of 1Mb (!). Win98 behavior may be different. At least on NT4.0, the only way to achieve finer granularity is to change the default stack size using editbin.exe.
11-06-2004
WORK AROUND Name: rlT66838 Date: 06/29/2000 Abort JNI. Switch to C++/VB/COM/DCOM, sockets, IDL etc. ====================================================================== john.coomes@eng 2001-02-16 Use editbin.exe to set the default thread stack size for the process or pass the -Xss<size> option on the java command line.
16-02-2001