Bug ID: JDK-5030087 HelloWorld throws Segmentation Fault on solx86 with -Xss64k

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 5.0

Priority: P2
Status: Closed
Resolution: Fixed
OS: solaris_8
CPU: x86

Submitted: 2004-04-12
Updated: 2004-05-06
Resolved: 2004-04-26

Other
5.0 b49Fixed


Name: vpR10197			Date: 04/12/2004


--------------------------------------
VM          : ServerVM
Mode        : -Xcomp
Platform    : x86
OS          : solaris
JDK         : since tiger-b40
----------------------------------------

The latest tiger builds cannot run the simpliest HelloWorld test with -Xss64k 
option. It throws 'Segmentation Fault'. This error was observed with
-server -Xcomp options on solx86 platform for java VM, (but it properly works
for java_g VM):

% cat -n HelloWorld.java 
     1  public class HelloWorld {
     2  
     3      public static void main(String argv[]) {
     4          System.out.println("Hello World");
     5      }
     6  
     7  }

% ../jdk1.5.0-b46/solaris-i586/bin/java -server -Xcomp  -Xss64k -cp . HelloWorld
Segmentation Fault

% ../jdk1.5.0-b40/solaris-i586/bin/java -server -Xcomp  -Xss64k -cp . HelloWorld
Segmentation Fault

% ../jdk1.5.0-b39/solaris-i586/bin/java -server -Xcomp  -Xss64k -cp . HelloWorld
Hello World

The test passes on all other platforms and modes.

Due to this bug, nsk test
    nsk/regression/b4287029
produces core-file that can be considered as a failure

======================================================================

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b49 tiger-beta2 VERIFIED IN: tiger-beta2
14-06-2004
EVALUATION ###@###.### 2004-04-14 The flag -Xss64k reduces the Compiler threads stack size. And it is not enough to compile nested inlining: 2 b java.lang.ThreadLocal$ThreadLocalMap::set (140 bytes) @ 10 java.lang.ThreadLocal::access$400 inline (hot) @ 33 java.lang.ThreadLocal$ThreadLocalMap$Entry::get inline (hot) @ 1 java.lang.ref.Reference::get inline (hot) @ 50 java.lang.ThreadLocal$ThreadLocalMap$Entry::access$602 inline (hot) @ 76 java.lang.ThreadLocal$ThreadLocalMap::nextIndex inline (hot) @ 98 java.lang.ThreadLocal$ThreadLocalMap$Entry::<init> inline (hot) @ 3 java.lang.ThreadLocal$ThreadLocalMap$Entry::<init> inline (hot) @ 2 java.lang.ref.WeakReference::<init> inline (hot) @ 2 java.lang.ref.Reference::<init> inline (hot) t@9 (l@9) signal SEGV (access to address exceeded protections) in _doprnt at 0xddac786d 0xddac786d: _doprnt+0x0009: pushl %ebx [t@9 l@9]: where current thread: t@9 =>[1] _doprnt(0xdd7120de, 0xd9df3fcc, 0xd9df376c), at 0xddac786d [2] vsnprintf(0xd9df37e8, 0x7d0, 0xdd7120de, 0xd9df3fcc), at 0xddacb115 [3] local_vsnprintf(0xd9df37e8, 0x7d0, 0xdd7120de, 0xd9df3fcc), at 0xdd5ff375 [4] outputStream::do_vsnprintf(0xd9df37e8, 0x7d0, 0xdd7120de, 0xd9df3fcc, 0x0, 0xd9df3fb8), at 0xdd601490 [5] outputStream::print(0x8070668, 0xdd7120de, 0x3), at 0xdd601532 [6] InlineTree::print_inlining(0x815c4a0, 0x8187e58, 0x3, 0xdd712028), at 0xdd2fdc4d [7] InlineTree::ok_to_inline(0x815c4a0, 0x8187e58, 0x81be918, 0xd9df409c, 0xd9df40b0), at 0xdd2fdfad [8] Compile::call_generator(0xd9dff2b8, 0x8187e58, 0x0, 0x81be918, 0x1, 0x3f800000), at 0xdd3b8f0d [9] Parse::do_call(0xd9df6318), at 0xdd3b93a9 [10] Parse::do_one_bytecode(), at 0xdd6181dc [11] Parse::do_one_block(0xd9df6318), at 0xdd6111c4 [12] Parse::visit_blocks(0xd9df6318), at 0xdd60e868 [13] Parse::do_all_blocks(0xd9df6318), at 0xdd60e706 [14] Parse::Parse(0xd9df6318, 0x81be858, 0x8187858, 0xbf800000), at 0xdd60e5d7 [15] ParseGenerator::generate(0x815c4d8, 0x81be858), at 0xdd3024c3 [16] Parse::do_call(0xd9df8608), at 0xdd3b9418 [17] Parse::do_one_bytecode(), at 0xdd6181dc [18] Parse::do_one_block(0xd9df8608), at 0xdd6111c4 [19] Parse::visit_blocks(0xd9df8608), at 0xdd60e868 [20] Parse::do_all_blocks(0xd9df8608), at 0xdd60e706 [21] Parse::Parse(0xd9df8608, 0x81be798, 0x8187260, 0xbf800000), at 0xdd60e5d7 [22] ParseGenerator::generate(0x815c460, 0x81be798), at 0xdd3024c3 [23] Parse::do_call(0xd9dfa8f8), at 0xdd3b9418 [24] Parse::do_one_bytecode(), at 0xdd6181dc [25] Parse::do_one_block(0xd9dfa8f8), at 0xdd6111c4 [26] Parse::visit_blocks(0xd9dfa8f8), at 0xdd60e868 [27] Parse::do_all_blocks(0xd9dfa8f8), at 0xdd60e706 [28] Parse::Parse(0xd9dfa8f8, 0x81be6d8, 0x8186c40, 0xbf800000), at 0xdd60e5d7 [29] ParseGenerator::generate(0x815c3e8, 0x81be6d8), at 0xdd3024c3 [30] Parse::do_call(0xd9dfcbe8), at 0xdd3b9418 [31] Parse::do_one_bytecode(), at 0xdd6181dc [32] Parse::do_one_block(0xd9dfcbe8), at 0xdd6111c4 [33] Parse::visit_blocks(0xd9dfcbe8), at 0xdd60e868 [34] Parse::do_all_blocks(0xd9dfcbe8), at 0xdd60e706 [35] Parse::Parse(0xd9dfcbe8, 0x81bdc28, 0x8183d10, 0xbf800000), at 0xdd60e5d7 [36] ParseGenerator::generate(0x815c370, 0x81bdc28), at 0xdd3024c3 [37] Parse::do_call(0xd9dfeed8), at 0xdd3b9418 [38] Parse::do_one_bytecode(), at 0xdd6181dc [39] Parse::do_one_block(0xd9dfeed8), at 0xdd6111c4 [40] Parse::visit_blocks(0xd9dfeed8), at 0xdd60e868 [41] Parse::do_all_blocks(0xd9dfeed8), at 0xdd60e706 [42] Parse::Parse(0xd9dfeed8, 0x81bcaf8, 0x8181d88, 0x3f800000), at 0xdd60e5d7 [43] ParseGenerator::generate(0x815bc98, 0x81bcaf8), at 0xdd3024c3 [44] Compile::Compile(0xd9dff2b8, 0xd9dffb90, 0x8070dd0, 0x8181d88, 0xffffffff, 0x1), at 0xdd35d1a1 [45] C2Compiler::compile_method(0x8070dd0, 0xd9dffb90, 0x8181d88, 0xffffffff), at 0xdd301b67 [46] CompileBroker::invoke_compiler_on_method(0x80706e8), at 0xdd365d61 [47] CompileBroker::compiler_thread_loop(), at 0xdd3654f3 [48] compiler_thread_entry(0x81b9508, 0x81b9508), at 0xdd698f29 [49] JavaThread::thread_main_inner(0x81b9508), at 0xdd6955ee [50] JavaThread::run(0x81b9508), at 0xdd695598 [51] _start(0x81b9508), at 0xdd5fa9d2 [52] _thr_setup(0xdda61000), at 0xddb64a59 [53] _lwp_start(), at 0xddb64ce0 The compiler method which eats most of stack is do_one_bytecode(). On solaris-x86 it reserves ~9K bytes of stack: __1cFParsePdo_one_bytecode6M_v_() 4510: 55 pushl %ebp 4511: 8b ec movl %esp,%ebp 4513: 81 ec 08 21 00 00 subl $0x2108,%esp One way to solve the problem is not inline the methods GraphKit::push(Node* n) and GraphKit::pop(Node* n). But it could hurt performance. The other is to prevent reducing the Compiler thread stack size which should be set by CompilerThreadStackSize variable. This variable is not used currently after the fix C2 recursive methods (4849017).
11-06-2004
WORK AROUND explicitly set compiler thread stack, e.g.: -XX:CompilerThreadStackSize=2K (in units of KB, which gives it a 2MB stack)
11-06-2004
SUGGESTED FIX ###@###.### 2004-04-20 Restore the use of CompilerThreadStackSize on Solaris. Use VMThreadStackSize for compiler thread if CompilerThreadStackSize is not specified. Use VMThreadStackSize for watcher thread. Adjust the VMThreadStackSize by K on Linux. http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/export2/archived_workspaces/main/c2_baseline/2004/20040420123748.kvn.5030087/workspace/webrevs/webrev-2004.04.20/index.html
11-06-2004