JDK-4927844 : Tomcat failed after 4 days when running with tiger b20 -server -Xcomp
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2003-09-25
  • Updated: 2009-11-16
  • Resolved: 2004-01-12
Related Reports
Duplicate :  
JDK-4937752 - vtest failed intermittenly when running with tiger b23 -server -Xcomp
Description
With tiger b20, Tomcat failed after 4 days when running with -server -Xcomp.

Test machine: j2se-app.west (email me if you need the root passwd)
j2se-app# uname -a
SunOS j2se-app 5.9 Generic_114466-01 sun4u sparc SUNW,Sun-Fire
j2se-app# /usr/j2se_b20/bin/java -server -Xcomp -version
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b20)
Java HotSpot(TM) Server VM (build 1.5.0-beta-b20, compiled mode)

There are multiple SIGKILL/SIGBUG in stack trace. ( Full stack trace is
attached with the bug report ). Below are two snippets.

  [5] VMError::report_and_die(0xb3dfefb8, 0xfeec5018, 0xffffffff, 0x0, 0xfeec505
0, 0x520c), at 0xfedc71f8
  [6] JVM_handle_solaris_signal(0x4, 0xb3dff498, 0xb3dff1e0, 0x7800, 0x6800, 0x3
c51a8), at 0xfea57af8
  [7] __sighndlr(0x4, 0xb3dff498, 0xb3dff1e0, 0xfea58300, 0x0, 0x0), at 0xff3861
a0
  [8] call_user_handler(0x4, 0xb3dff498, 0xb3dff1e0, 0x0, 0x0, 0x0), at 0xff37fe
d0
  [9] sigacthandler(0x4, 0xb3dff498, 0xb3dff1e0, 0x4f4ba0, 0x3c51a8, 0x0), at 0x
ff380080
  ---- called from signal handler with signal 4 (SIGILL) ------
  [10] 0xb540a5a8(0xe3fc75e8, 0xe3fb7ae0, 0x0, 0xf9815f80, 0x55a4, 0xb3dff5a0),
at 0xb540a5a7




  [4] VMError::report_and_die(0xb26fe570, 0xfeec5018, 0xa, 0xfe9456ac, 0x7400, 0
x5000), at 0xfedc72b8
  [5] JVM_handle_solaris_signal(0xa, 0xb26fea50, 0xb26fe798, 0x7800, 0x6800, 0x4
f7110), at 0xfea57af8
  [6] __sighndlr(0xa, 0xb26fea50, 0xb26fe798, 0xfea58300, 0x0, 0x0), at 0xff3861
a0
  [7] call_user_handler(0xa, 0xb26fea50, 0xb26fe798, 0x0, 0x0, 0x0), at 0xff37fe
d0
  [8] sigacthandler(0xa, 0xb26fea50, 0xb26fe798, 0x4f7330, 0x4f732c, 0x52ccf4),
at 0xff380080
  ---- called from signal handler with signal 10 (SIGBUS) ------
  [9] LinkResolver::runtime_resolve_virtual_method(0xb26ff3d8, 0x4f7338, 0x6ff9a
a45, 0x7, 0xb26febfc, 0x1), at 0xfe9456ac
  [10] LinkResolver::resolve_invokevirtual(0x4f7310, 0x0, 0x4f732c, 0x0, 0x4f711
0, 0x4f731c), at 0xfe956410
  [11] LinkResolver::resolve_invoke(0xb26ff3d8, 0xb26fedb8, 0xb26fedb4, 0x30, 0x
b6, 0x4f7110), at 0xfe9385e4
  [12] SharedRuntime::find_callee_info_helper(0xb26ff3d0, 0x4f7110, 0x4f76c4, 0x
b26ff3d4, 0xb26ff3d8, 0x4f7110), at 0xfe99ea14
  [13] SharedRuntime::resolve_helper(0x0, 0x4f7110, 0x1, 0x1, 0x4f7110, 0x49ec6c
), at 0xfe9b1a30
  [14] OptoRuntime::resolve_opt_virtual_call_C(0x4f7110, 0xe3fb7ae0, 0x0, 0xf981
5f80, 0x55a4, 0x6), at 0xfe9bd578


###@###.### 2003-09-24
Comments
EVALUATION Mail from ###@###.###: " You are right. I have reproduced both 4927844(tomcat one) and 4937752(vtest one) with b32 using -server -Xcomp. And the stack traces are very much alike. ( I am not able to update bug report from home PC, so I am sending you the stack trace and the output from jstack ) The bug 4927844 is reproducible with b32 on a v880 machine ( bigapp-880-1.red.iplanet.com, 8 cpus 900MHZ, root passwd "iplanet" ) The stack trace of the tomcat crash on bigapp-880-1 is: ---- called from signal handler with signal 10 (SIGBUS) ------ [10] 0xf8815d44(0xe49a1fb8, 0xb7, 0x0, 0xf8815b20, 0xe4a4e480, 0xb2f7f6a0), at 0xf8815d43 [11] 0xf8805664(0xe49a1fa0, 0xb7, 0x0, 0xf8815dc8, 0xe4a4e480, 0xb2f7f728), at 0xf8805663 [12] 0xf8805664(0xfffffff9, 0x1d1170, 0x0, 0xf8815dc8, 0x1, 0xb2f7f7c0), at 0x f8805663 [13] 0xf8838174(0xe49a1ed0, 0x5, 0x3f0328, 0x45da28, 0x2, 0xfeeaa000), at 0xf8838173 [14] 0xf8958cac(0xe49a1ed0, 0xe49a1ed0, 0x0, 0x0, 0xe4a4e480, 0x0), at 0xf8958cab [15] 0xf8845b30(0xe49a1ed0, 0xb6, 0xe6e5d108, 0xe6e5d108, 0x80000000, 0xb2f7f888), at 0xf8845b2f [16] 0xf8805774(0xf8838150, 0x1d1170, 0x0, 0xf8815b20, 0x139e00, 0xb2f7f960),at 0xf8805773 [17] 0xf8838174(0xe2c4adf0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xf8838173 [18] 0xf887db10(0xe2c4beb8, 0xb2f7faf8, 0x0, 0x139e00, 0x260300, 0x80000000),at 0xf887db0f [19] 0xf8838370(0x0, 0xfeef64d0, 0xff31aa04, 0xfef0dd94, 0x6b18, 0x0), at 0xf883836f [20] 0xf8800118(0xb2f7fb10, 0xb2f7fd10, 0xa, 0xb402b5f0, 0xf880a6e0, 0xb2f7fc28), at 0xf8800117 [21] JavaCalls::call_helper(0x1, 0x139e00, 0xb2f7fc20, 0xb2f7fb20, 0x1, 0xf880 00c0), at 0xfe98086c [22] JavaCalls::call_virtual(0x7f24, 0x139e00, 0x1d1178, 0x1d1184, 0x1d1180, 0xe2c4beb8), at 0xfea8f754 [23] thread_entry(0xb402d250, 0x139e00, 0x1d1564, 0xfef0f1b8, 0xfef0f280, 0xff0ecc8), at 0xfeaacd4c [24] JavaThread::run(0x139e00, 0x1, 0x2, 0xfeeecd98, 0xfeeecd94, 0xb2f00000),at 0xfeaa7950 [25] _start(0x139e00, 0x5800, 0x5b7, 0x444c, 0xfeeaa000, 0x3ce258), at 0xfeaa3b64 And jstackproc shows: Thread t@27: (state = IN_JAVA, current Java SP = null) - java.net.Socket.<init>(java.net.SocketAddress, java.net.SocketAddress, boolea n) @bci=51, line=351, pc=0xf880566c, methodOop=0xb41cc0f0 (Interpreted frame) - java.net.Socket.<init>(java.lang.String, int) @bci=38, line=178, pc=0xf880566 c, methodOop=0xb41cbc68 (Interpreted frame) - atg.core.net.HTTPConnection.openSocket() @bci=30, line=147, pc=0xf880566c, me thodOop=0xb41c5648 (Interpreted frame) - atg.core.net.HTTPConnection.connect() @bci=8, line=28, pc=0xf8958cb4, methodO op=0xb41c4e58 (Compiled frame) - atg.core.net.URLHammerThread.run() @bci=252, line=169, pc=0xf880577c, methodO op=0xb41c1828 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=566, pc=0xf887db18, methodOop=0xb402b5f0 (Compiled frame) In bug report 4937752 Ross wrote: "With a lot of help from Ken Russell and hsdb, it looks like java/net/Socket.<init>(Ljava/lang/String;I)V has a duplicated object on it's interpreter stack causing java/net/Socket.<init>(Ljava/net/SocketAddress;Ljava/net/SocketAddress;Z)V to initialize the wrong object, evenually causing the linkresolver to error." So is it possible that the tomcat crash is also caused by a duplicate object on java/net/Socket.<init>(Ljava/lang/String;I)V's interpreter stack ? The output from jstackproc indicates at the time tomcat crashed, a java/net/Socket was being initialized. " I am going to close this as a dup of 4937752 . I haven't been able to reproduce it myself. It's been running for 2 weeks on my 4 proc 450mhz solaris/sparc machine. ###@###.### 2004-01-12
12-01-2004