JDK-6511772 : JVM crash with 1.4.2_10
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2_10,1.4.2_12
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux_redhat_6.2,solaris_8
  • CPU: generic,x86
  • Submitted: 2007-01-10
  • Updated: 2010-08-06
  • Resolved: 2009-04-30
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-poolResolved
Related Reports
Duplicate :  
JDK-6511783 - JVM crash with 1.4.2_10
Relates :  
JDK-4720694 - java apps crash on Solaris 9 Ultra-80 machine by using 1.4.1
Relates :  
JDK-6583347 - compute_exception_return_address() can fail during stack overflow.
Relates :  
JDK-5081594 - arguments008 fails an assertion
Description
Java application is running with Weblogic 8.1, MQSeries and 1.4.2_10 on a Solaris system.
The application was running well prior to upgrading Weblogic from 6.1 to 8.1 and now several problems have been seen including the crash with the stack trace below:

t@58 (l@58) terminated by signal ABRT (Abort)
0xff29f2dc: __lwp_kill+0x0008:  bgeu,a   __lwp_kill+0x1c        ! 0xff29f2f0
(dbx) where
current thread: t@58
=>[1] __lwp_kill(0x0, 0x3a, 0x0, 0xff2bc008, 0xff366000, 0x0), at 0xff29f2dc 
  [2] raise(0x6, 0x0, 0x0, 0xffffffff, 0xff2c03c4, 0x0), at 0xff24bcec 
  [3] abort(0xff2bc008, 0x1, 0x1, 0xff165b81, 0x1, 0xef800000), at 0xff235984 
  [4] os::abort(0x1, 0xff165b81, 0x1, 0x7efefeff, 0x81010100, 0xff00), at 0xff0a13a4 
  [5] VMError::report_and_die(0xff17bc98, 0xff17bca7, 0xff17bcb7, 0xff171f57, 0x14f, 0xe0000000), at 0xff105d98 
  [6] report_fatal(0xff171f57, 0x14f, 0xff171fa4, 0x0, 0x0, 0x0), at 0xfef80ddc 
  [7] SharedRuntime::compute_exception_return_address(0x1, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfee98f64 
  [8] 0xefc36d20(0xefe9aac8, 0x0, 0xff1be568, 0x1, 0x0, 0x7a87eb18), at 0xefc36d20 
  [9] CompiledCodeSafepointHandler::handle_illegal_instruction_exception(0x4ea028, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfee0ab5c 
  [10] 0xefc32608(0x8fa32570, 0x8f8008b0, 0x0, 0x4, 0x20, 0xe39a5260), at 0xefc32608 
  [11] 0xefcafde0(0x20, 0x85205258, 0x85205270, 0x852052a0, 0xbc, 0xb8), at 0xefcafde0 
  [12] 0xf0036694(0x85205168, 0x852051b0, 0x85205158, 0x85205258, 0x63, 0xe58fbf28), at 0xf0036694 

From hs_err log we see:

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (53484152454432554E54494D450E435050014F 01), pid=15856, tid=58
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2_10-b03 mixed mode)

I've attached hs_err log, core file, and related libraries to this report.

The stack trace seems to be similar to one seen in a web server bug reported in CR: 4927770 which references a java bug CR: 4720694.  However the java bug should have been addressed in mantis and fixed by now.
Comments
EVALUATION Closing as not reproducible for now. Customer cases no longer open. If this happens again or some other link is made we can look again.
30-04-2009
EVALUATION As discussed with Steve and Coleen, the bug is the ThreadCodeBuffer is NULL: frame caller_fr = stub_fr.sender_for_raw_compiled_frame(&map); // Step 3: Calculate real return address if (ShowSafepointMsgs && Verbose) { tty->print_cr("illegal instruction exception at " INTPTR_FORMAT, thread()->saved_exception_pc()); } address real_return_addr = cbuf->compute_adjusted_pc(thread()->saved_exception_pc()); thread()->set_saved_exception_pc(NULL); // clear exception pc The call of compute_adjusted_pc caused a SEGV and code is in CompiledCodeSafepointHandler::handle_illegal_instruction_exception which is "in_Java" and runtime think it is a NPE, then caused the stack trace like this. Check frame 9, $l2 is cbuf, which is NULL. 0x50d8a8 is Thread* (dbx) x 0x50d8a8+200 // is ThreadSafepointState 0x0050d970: 0x0050e2b8 (dbx) x 0x0050e2b8+20 // ThreadCodeBuffer 0x0050e2cc: 0x00000000 The bug seems related to 4720694 which fixed in 142_10 and used in this core file. The race condition seems still exists, the code buffer had been removed by VMThread before this java thread reached here.
13-01-2007