JDK-4694035 : Tomcat hang on solaris with build 13 after 95 hours in C2 mode & b18 after 15 hr
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.1
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_8
  • CPU: generic,sparc
  • Submitted: 2002-05-30
  • Updated: 2002-10-01
  • Resolved: 2002-09-25
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 Other
1.4.1_01 01Fixed 1.4.2Fixed
Related Reports
Duplicate :  
JDK-4712498 - hopper: b16: stress test crashes ServerVM in -Xcomp mode on Solaris-sparc
Duplicate :  
JDK-4695523 - stress test intermittently crashes Server VM in -Xcomp mode
Description
With hopper b13, on jtgb4u2c, (Solaris8 sparc ), Tomcat hang in C2 mode
after 95 hours.

The crash is in thread 69. See stack trace below.
  [7] sigacthandler(0xb, 0xedd81d70, 0x0, 0x0, 0x0, 0xff37e000), at 0xff3684c0
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [8] 0xfa40b4d0(0xfa43baa0, 0xfe584000, 0x0, 0x141d48, 0x0, 0xf), at 0xfa40b4cf
  [9] nmethod::interpreter_entry_point(0xedd81484, 0x141d48, 0x0, 0x0, 0xedd814c
4, 0x0), at 0xfe2044fc
  [10] 0xfa4367b0(0xf2073a98, 0xf60db938, 0xfa442a08, 0xfa416808, 0x0, 0xedd8144
8), at 0xfa4367af
  [11] 0xfa43bad0(0xf2073a98, 0xedd8158c, 0xedd81590, 0xf61527a6, 0x14, 0x0), at
 0xfa43bacf
 [12] 0xfa405984(0xedd8159c, 0xf2073940, 0x0, 0xfa418650, 0x4, 0xedd814d0), at
0xfa405983
  [13] 0xfa443e3c(0xf2073a98, 0xf2073a50, 0xf61527e8, 0x0, 0x10, 0xedd81550), at
 0xfa443e3b
  [14] 0xfa44ac20(0xf2072b90, 0x11, 0x0, 0xf, 0x4, 0x1), at 0xfa44ac1f
  [15] 0xfa43bad0(0xf2072b90, 0xedd81738, 0x0, 0xfa418390, 0x4, 0xedd815d8), at
0xfa43bacf
  [16] 0xfa405984(0xedd8173c, 0xedd817c0, 0x0, 0xfa418390, 0x4, 0xedd81660), at
0xfa405983
  [17] 0xfa405984(0xedd817c4, 0x9, 0x0, 0xfa418390, 0x4, 0xedd816e0), at 0xfa405
983
  [18] 0xfa4058d0(0xedd8188c, 0xf6020ea0, 0x0, 0xfa418390, 0x4, 0xedd81758), at
0xfa4058cf
  [19] 0xfa405c0c(0xedd81904, 0x0, 0x0, 0xfa4189b0, 0x4, 0xedd81830), at 0xfa405
c0b
  [20] 0xfa40010c(0xedd81994, 0xedd81c08, 0xa, 0xf6021ac0, 0x4, 0xedd818a8), at
0xfa40010b
  [21] JavaCalls::call_helper(0xedd81c00, 0xedd81a60, 0xedd81b20, 0x141d48, 0x14
1d48, 0xedd81a74), at 0xfe1282c0
  [22] JavaCalls::call_virtual(0xfe584000, 0x1422e0, 0xedd81b14, 0xedd81b10, 0xe
dd81b20, 0x141d48), at 0xfe21fe98
  [23] JavaCalls::call_virtual(0xedd81c00, 0xedd81bfc, 0xedd81bf0, 0xedd81be8, 0
xedd81be0, 0x141d48), at 0xfe229664
  [24] thread_entry(0x141d48, 0x141d48, 0x13a378, 0x1422e0, 0x343a48, 0xfe240c08
), at 0xfe242cb8
  [25] JavaThread::run(0x141d48, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfe240c30

How to reproduce the bug: ( The bug is highly intermitten, it may be
very difficult to reproduce it ) I saved the test log along with core files
under /net/jtgb4u4c/export/sail6/bigapps_log/solaris/hopper_b13/jtgb4u2c
1. telnet to jtgb4u2c
2. export JAVA_HOME=<your java home>
3. run the script /bs/runtomcat.ksh -server
4. go to /bt/Tomcat*server to view the log files. If the file "run.tomcat.out"
is not up-to-date, the app probably crashs.
 
###@###.### 2002-05-30

The failure showed up in build 18 on jtg-e250-2 (Solaris Sparc) after 18 hours.
it's failing in a I2C Adapter.
The processes are still alive on jtg-e250-2.sfbay. I also saved gcore files
under /bt/Tomcat*

###@###.### 2002-07-26

The failure shows up in build 19 on jtg-e250-2 after 10 days 9 hours.

###@###.### 2002-08-19
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_01 mantis FIXED IN: 1.4.1_01 mantis INTEGRATED IN: 1.4.1_01 mantis
14-06-2004
EVALUATION ###@###.### 2002-07-30 If the stack is not corrupt, the following trace indicates that the crash does not occur in c2 generated code, but in c2 specific runtime support. That is, obtaining an I2CAdapter either by lookup in the I2CAdapterGenerator's cache, or by having the CompileBroker request compilation from a CompileThread. [7] sigacthandler(0xb, 0xece81d70, 0x0, 0x0, 0x0, 0xff37e000), at 0xff368504 ---- called from signal handler with signal 11 (SIGSEGV) ------ [8] 0xfa40a170(0xfa4418a0, 0xfe584000, 0x1, 0xf2157588, 0xf21574a8, 0xf2157518), at 0xfa40a16f [9] nmethod::interpreter_entry_point(0xedd81484, 0x141d48, 0x0, 0x0, 0xedd814c4, 0x0), at 0xfe2044fc ----- This bug occurs when an interpreted to compiled (I2C) stub calls a compiled to interpreted (C2I) stub. This is a rare occurrance which can happen if the code for a method is invalidated (due to an uncommon trap or an inlining constraint violated by class loading) between the time the interpreter decides that the method it is calling has compiled code, and the I2C stub is executed. The bug occurs because the I2C stub overwrites the register containing the methodOop for the destination method with the address of the code being called. This is ok for calling compiled code, but a C2I stub expects the register to contain the methodOop. The C2I stub is entered with a register which should contain a methodOop, holding the address of the stub instead. The C2I stub tests the _code field of the methodOop. The bad methodOop only causes a problem if the value at the offset corresponding to the _code field is 0. In this case the interpreter is passed the garbage methodOop causing a SEGV. This bug has only been observed on SPARC, but the register is also overwritten on Intel which could trigger the same bug. ###@###.### 2002-08-15 The fix was to change the code sequence on SPARC to use a different scratch register for the call. On Intel, we now do an indirect call through the methodOop field containing the target address rather than loading it into a register first. ###@###.### 2002-08-23
23-08-2002