Bug ID: JDK-4758894 SPECjAppServer2001 crashes appserver on Linux

Versions (Unresolved/Resolved/Fixed)

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
1.4.1_03 03Fixed

Please see app server bug 4757880.

             Am able to reproduce the problem on Linux Sep15 release. 

             The appserver startes and appservd processes start the JDK. When the SpecJ is 
             run, the JDK dies with SIGSEGV (segmentation fault - invalid memory reference).

             The deamon process captures all the signal handlers and handles SIGSEGV in the 
             default manner (print and error message). It then detects that the child process 
             has crached and restarts the JVM.

             Since the child prcess here is the JVM, I havent explored what causes the 
             problem. It is suffice to say that under stress the JVM crashes. To further 
             prove this theory, I tried replacing the JVM with an older one (1.4.0). On this 
             JVM I am able to get the results of the benchmark.

             Again switching to JDK 1.4.0_02 make the appserver crash. I havent tried with 
             JDK 1.4.0_01 and would be as soon as I find the bits.

             This is clearly a JDK issue under load.

             Also woul dbe testing on 1.4.0_03 to confirm this as 1.4.0_03 is slated to be 
             the JVM we would be shipping.

             This Bug arises only on JDK version 1.4.0_02 for Linux.

---
Due to 4741681 and 4629175 App server will probably need to certify on 1.4.1 (or maintenance release)


Mon Oct 07 10:42:50 MDT 2002	tsteele@litehouse

Mon Oct 07 21:20:18 MDT 2002	sm119578

a

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_03 FIXED IN: 1.4.1_03 INTEGRATED IN: 1.4.1_03
14-06-2004
EVALUATION ###@###.### 2002-12-26 This bug is a regression caused by bug 4738340. For mantis, the fix has already been integrated by coleen phillimore The exception oop has to be stored when the exception is passed up. I will be making the necessary changes and fix this bug for 1.4.1_03 Some more technical details. The exception oop should have been saved. The problem is manifesting as GC examining this exception oop later and bombing. By doing thread->set_vm_result(exception), the exception oop is stored and hence the pointers are valid when the GC happens. This bug should've existed in the sparc version too but somehow it was never caught.
11-06-2004
SUGGESTED FIX ###@###.### 2003-01-22 hotspot/src/share/vm/interpreter sccs diffs -C interpreterRuntime.cpp ------- interpreterRuntime.cpp ------- * /tmp/sccs.DKaatn Wed Jan 22 17:22:46 2003 --- interpreterRuntime.cpp Fri Dec 27 01:44:23 2002 *********** * 227,233 **** --- 227,238 ---- // into java, or surprisingly find a matching exception handler for bci 0 // since at this moment the method hasn't been "officially" entered yet. if (thread->do_not_unlock_if_synchronized()) { + thread->set_vm_result(exception); + #ifdef CC_INTERP + return (address) -1; + #else return Interpreter::remove_activation_entry(); + #endif } Handle h_exception(thread, exception);
11-06-2004
WORK AROUND 1.4.0_01 works fine -Xint works fine ###@###.### 2002-10-26 -Xconcgc goes through successfully and this definitely is the best workaround for now which can be used. ###@###.### 2002-10-29
26-10-2002