Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 4704990
Votes 3
Synopsis JDK 1.4.0_01 crashes with Weblogic 6.1 sp2
Category hotspot:compiler2
Reported Against 1.4.0_01
Release Fixed 1.4.0_03
State 10-Fix Delivered, bug
Priority: 1-Very High
Related Bugs 4963043
Submit Date 20-JUN-2002
Description
Summary: JDK 1.4.0_01 hotspot crashes with Weblogic 6.1 sp 2

Load-balancer hits SSL accelerator
hits Java web server
hits java app server
hits Oracle DB server
System crashing is the Java web server (Weblogic 6.1 sp2)

Java options: -server -ms2048m -mx2048m -Xmn682m -Xfuture -Xnoclassgc 
it works with -client, but they need to implement it w/-server

Using Type 2 drivers, can't use put java drivers because Oracle's thin driver 
has a problem with BLOBs > 4kb.

*******************************************************************************

ERROR MESSAGE:
Unexpected Signal : 11 occurred at PC=0xFED5C4F8
Function=[Unknown. Nearest: JVM_GetCPMethodNameUTF+0x17B8]
Library=/opt/p4/java/sunos-sparc/1.4.0_01/jre/lib/sparc/server/libjvm.so

Current Java thread:

Dynamic libraries:
0x10000         /opt/p4/java/sunos-sparc/1.4.0_01/jre/../bin/java
0xff360000      /usr/lib/lwp/libthread.so.1
0xff390000      /usr/lib/libdl.so.1
0xff280000      /usr/lib/libc.so.1
0xff350000      /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1
0xfec00000 
/opt/p4/java/sunos-sparc/1.4.0_01/jre/lib/sparc/server/libjvm.so
0xfebd0000      /usr/lib/libCrun.so.1
0xfeba0000      /usr/lib/libsocket.so.1
0xfea80000      /usr/lib/libnsl.so.1
0xfeb70000      /usr/lib/libm.so.1
0xff260000      /usr/lib/libw.so.1
0xfeb40000      /usr/lib/libmp.so.2
0xfea60000      /usr/lib/librt.so.1
0xfea40000      /usr/lib/libaio.so.1
0xfea00000 
/opt/p4/java/sunos-sparc/1.4.0_01/jre/lib/sparc/native_threads/libhpi.so
0xfe9c0000      /opt/p4/java/sunos-sparc/1.4.0_01/jre/lib/sparc/libverify.so
0xfe980000      /opt/p4/java/sunos-sparc/1.4.0_01/jre/lib/sparc/libjava.so
0xfe950000      /opt/p4/java/sunos-sparc/1.4.0_01/jre/lib/sparc/libzip.so
0xfe6e0000      /usr/lib/nss_files.so.1
0xb6620000      /opt/p4/java/sunos-sparc/1.4.0_01/jre/lib/sparc/libnet.so
0xb6560000      /opt/p4/weblogic/6.1sp2/lib/solaris/libmuxer.so
0xb6540000      /usr/ucblib/libucb.so.1
0xb6520000      /usr/lib/libresolv.so.1

0xb6440000      /usr/lib/libelf.so.1

Local Time = Mon Jun 17 16:23:58 2002
Elapsed Time = 1127
#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002D5 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Server VM (1.4.0_01-b03 mixed mode)
#

*******************************************************************************

STACK TRACE (using regular jdk, not debug):
>>>  xxxxx@xxxxx  :~/p4/ customer /main/deploy/stage/weblogic> dbx `which 
>>>java` core
>>>For information about new features see `help changes'
>>>To remove this message, put `dbxenv suppress_startup_message 7.0' in 
>>>your .dbxrc
>>>Reading java
>>>core file header read successfully
>>>Reading ld.so.1
>>>Reading libthread.so.1
>>>Reading libdl.so.1
>>>Reading libc.so.1
>>>Reading libc_psr.so.1
>>>Reading libjvm.so
>>>Reading libCrun.so.1
>>>Reading libsocket.so.1
>>>Reading libnsl.so.1
>>>Reading libm.so.1
>>>Reading libw.so.1
>>>Reading libmp.so.2
>>>Reading librt.so.1
>>>Reading libaio.so.1
>>>Reading libhpi.so
>>>Reading libverify.so
>>>Reading libjava.so
>>>Reading libzip.so
>>>Reading nss_files.so.1
>>>Reading libnet.so
>>>Reading libmuxer.so
>>>Reading libucb.so.1
>>>Reading libresolv.so.1
>>>Reading libelf.so.1
>>>detected a multithreaded program
>>>  xxxxx@xxxxx   (  xxxxx@xxxxx  ) terminated by signal ABRT (Abort)
>>>0xff31bee0: _lwp_kill+0x0008:   bgeu,a  _lwp_kill+0x1c
>>>(dbx) where
>>>current thread:   xxxxx@xxxxx  
>>>=>[1] _lwp_kill(0x0, 0x9, 0x0, 0xff33a004, 0xff386000, 0xff33e440), at 
>>>0xff31bee0
>>>  [2] raise(0x6, 0x0, 0x0, 0xffffffff, 0xff33e3cc, 0x0), at 0xff2cb738
>>>  [3] abort(0xff33a004, 0xb5f7df88, 0x0, 0x4, 0x0, 0xb5f7dfa9), at 
>>>0xff2b5aac
>>>  [4] os::abort(0x1, 0xff16d0f8, 0xb5f7e028, 0x0, 0xff1ecfbc, 
>>>0xff075e90), at 0xff077440
>>>  [5] os::handle_unexpected_exception(0xe25d0, 0xb, 0xfed5c4f8, 
>>>0xb5f7ed70, 0xfed3cd00, 0x0), at 0xff075f00
>>>  [6] JVM_handle_solaris_signal(0xfed5c4f8, 0xb5f7ed70, 0xb5f7eab8, 
>>>0xfed5c4fc, 0xfed5c4f8, 0x0), at 0xfed3d578
>>>  [7] __sighndlr(0xb, 0xb5f7ed70, 0xb5f7eab8, 0xfed3cc9c, 0x0, 0x0), at 
>>>0xff374c8c
>>>  [8] call_user_handler(0xfe7a0e00, 0x9, 0xff3878e0, 0xb5f7eab8, 
>>>0xb5f7ed70, 0xb), at 0xff36fadc
>>>  [9] sigacthandler(0xfe7a0e00, 0xb5f7ed70, 0xb5f7eab8, 0xff386000, 
>>>0xb5f7ed70, 0xb), at 0xff36fca8
>>>  ---- called from signal handler with signal 11 (SIGSEGV) ------
>>>  [10] GraphKit::kill_dead_locals(0xb5f7f194, 0xa3350, 0x0, 0xb3d440, 
>>>0x15c804, 0x4400), at 0xfed5c4f8
>>>  [11] Parse::do_checkcast(0x3befd8, 0x1, 0x4000, 0x400c, 0xa2f78, 
>>>0xfed10c24), at 0xfee4c318
>>>  [12] Parse::do_one_bytecode(0xb5f7f194, 0xb3e090, 0x0, 0x169a88, 
>>>0x1695a8, 0xf763a2b0), at 0xfed17ca8
>>>  [13] Parse::do_one_block(0xb5f7f194, 0x57c794, 0x1, 0x4b8e74, 
>>>0xfed981b4, 0xb3a8c0), at 0xfed5f354
>>>  [14] Parse::Parse(0xb5f7f194, 0x99b2b0, 0x1695a8, 0x46728400, 
>>>0xff1d4000, 0x99b319), at 0xfed98530
>>>  [15] ParseGenerator::generate(0x57c6f4, 0x99b2b0, 0x4, 0xb3ab50, 
>>>0xb5f7f504, 0x0), at 0xfed986dc
>>>  [16] Compile::Compile(0x57c6f4, 0x3bcf94, 0x0, 0x1695a8, 0xffffffff, 
>>>0x1), at 0xfee2a680
>>>  [17] C2Compiler::compile_method(0xdfd20, 0xb5f7fd58, 0x0, 0x1695a8, 
>>>0xffffffff, 0x0), at 0xfee24c20
>>>  [18] CompileBroker::invoke_compiler_on_method(0x237, 0x0, 0xffffffff, 
>>>0xff1e2edc, 0xff20095c, 0xeb740), at 0xfee2567c
>>>  [19] CompileBroker::compiler_thread_loop(0xe25d0, 0xe25d0, 0xea960, 
>>>0xe7248, 0x343048, 0xfee9165c), at 0xfeefd114
>>>  [20] JavaThread::run(0xe25d0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfee91684
>>>  [21] _start(0xe25d0, 0xfe7a0e00, 0x0, 0x0, 0x0, 0x0), at 0xfee86fb4

>>>(dbx) thread -info   xxxxx@xxxxx  
>>>        Thread   xxxxx@xxxxx   (0xfe7a0e00) at priority 64
>>>        state: bound to      xxxxx@xxxxx  
>>>        base function: 0xfee86f94: _start() stack: 0xb5f80000[2097152]
>>>        flags: BOUND|DETACHED|SUSPENDED
>>>        masked signals: HUP INT QUIT ILL TRAP EMT FPE BUS SEGV SYS PIPE 
>>>ALRM TERM USR1 USR2 CLD PWR WINCH URG POLL TSTP CONT TTIN TTOU VTALRM 
>>>PROF XCPU XFSZ FREEZE THAW LOST RTMIN RTMIN+1 RTMIN+2 RTMIN+3 RTMIN+4 
>>>RTMIN+5 RTMIN+6 RTMIN+7
>>>        Currently active in _lwp_kill
Work Around
N/A
Evaluation
Please try 1.4.1 from web and let us know the results of that  run.


  xxxxx@xxxxx   2002-06-21

Could bug submitter please add a testcase so we can look into this further.

  xxxxx@xxxxx   2002-06-21

The java_g assertion makes it very likely that the bug arises when
the call to do_null_assert in do_checkcast stops the parser, but
do_null_assert does not check for this condition.

(I can't tell for sure that this has happened without stepping through
the execution of the failing compilation, which appears infeasible.
But note that the previous call to peek in do_checkcast includes the
same assert, which did not fail; do_null_assert is the only action
that seems able to change the map between the call to peek and the
call to kill_dead_locals.)

In any case, the fix for this bug is already in Hopper (1.4.1),
and is small, targeted, low-risk, and easy to back-port.  I have
extracted the diff from Hopper and put it in the Suggested Fix.

  xxxxx@xxxxx   2002-07-10
Comments
  
  Include a link with my name & email   

Submitted On 31-JUL-2002
joshuaPressnell
I am having the same error using Sun's SSL sockets in Jetty.  
I downloaded the 1.4.1 release and the JRE still blows up.  
Everything works fine until I close the browser window that is 
using https and then it dies with the above error.



PLEASE NOTE: JDK6 is formerly known as Project Mustang