JDK-5005986 : 64bit j2sdk1.4.2_01 and j2sdk1.4.2_03 dump core with oracle 64bit jdbc oci driv
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2,1.4.2_01,1.4.2_04
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8,solaris_9
  • CPU: generic,sparc
  • Submitted: 2004-03-02
  • Updated: 2012-10-08
  • Resolved: 2004-06-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.
1.4.2_06 06Fixed
Name: wm7046			Date: 03/01/2004

We built 64bit jdbc oci driver on Sparc64 (SunOS 5.8) for Oracle 10g release and wanted to certify it with 64bit jdk.
j2sdk1.4.2_02 worked fine.  However Oracle decided that the 10g RDBMS release will be shipping with JDK 1.4.2_01.
With 64bit JDK 1.4.2_01 and JDK 1.4.2_03 we got a core when running jdbc regression tests. The stack looks like
the following,

Unexpected Signal : 11 occurred at PC=0xFFFFFFFF7D18F650
Function=[Unknown. Nearest: SUNWprivate_1.1+0x18F650]

Dynamic libraries:
0x100000000     /usr/local/packages/j2sdk1.4.2_01/bin/sparcv9/java
0xffffffff7f200000      /usr/lib/64/libthread.so.1
0xffffffff7f400000      /usr/lib/64/libdl.so.1
0xffffffff7ef00000      /usr/lib/64/libc.so.1
0xffffffff7ed00000      /usr/platform/SUNW,Ultra-80/lib/sparcv9/libc_psr.so.1
0xffffffff7d000000      /usr/local/packages/j2sdk1.4.2_01/jre/lib/sparcv9/server
0xffffffff7d800000      /usr/lib/64/libCrun.so.1
0xffffffff7ce00000      /usr/lib/64/libsocket.so.1
0xffffffff7cb00000      /usr/lib/64/libnsl.so.1
0xffffffff7c900000      /usr/lib/64/libm.so.1
0xffffffff7c700000      /usr/lib/64/libsched.so.1
0xffffffff7da00000      /usr/lib/64/libw.so.1
0xffffffff7c300000      /usr/lib/64/libmp.so.2
0xffffffff7c100000      /usr/local/packages/j2sdk1.4.2_01/jre/lib/sparcv9/native
0xffffffff7bc00000      /usr/local/packages/j2sdk1.4.2_01/jre/lib/sparcv9/libver
0xffffffff7ba00000      /usr/local/packages/j2sdk1.4.2_01/jre/lib/sparcv9/libjav
0xffffffff7b700000      /usr/local/packages/j2sdk1.4.2_01/jre/lib/sparcv9/libzip
0xffffffff2f400000      /usr/lib/locale/en_US/sparcv9/en_US.so.2
0xffffffff2e800000      /project/qa/dev/juli/01021/dbjava/lib/libocijdbc10.so
0xffffffff2d400000      /project/qa/dev/juli/01021/lib/libclntsh.so.10.1
0xffffffff2d000000      /project/qa/dev/juli/01021/lib/libnnz10.so
0xffffffff2e500000      /usr/lib/64/libgen.so.1
0xffffffff2ce00000      /usr/lib/64/libkstat.so.1
0xffffffff2cc00000      /usr/lib/64/libaio.so.1
0xffffffff2ca00000      /usr/lib/64/librt.so.1

Heap at VM Abort:
 def new generation   total 2112K, used 2112K [0xffffffff2f800000, 0xffffffff2fa
20000, 0xffffffff30d50000)
  eden space 2048K, 100% used [0xffffffff2f800000, 0xffffffff2fa00000, 0xfffffff
  from space 64K, 100% used [0xffffffff2fa00000, 0xffffffff2fa10000, 0xffffffff2
  to   space 64K,   8% used [0xffffffff2fa10000, 0xffffffff2fa116a0, 0xffffffff2
 tenured generation   total 1408K, used 288K [0xffffffff30d50000, 0xffffffff30eb
0000, 0xffffffff33800000)
   the space 1408K,  20% used [0xffffffff30d50000, 0xffffffff30d98040, 0xfffffff
f30d98200, 0xffffffff30eb0000)
 compacting perm gen  total 16384K, used 4996K [0xffffffff33800000, 0xffffffff34
800000, 0xffffffff37800000)
   the space 16384K,  30% used [0xffffffff33800000, 0xffffffff33ce1268, 0xffffff
ff33ce1400, 0xffffffff34800000)

Local Time = Fri Jan 16 16:06:30 2004
Elapsed Time = 8
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002EF 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.4.2_01-b06 mixed mode)

An oracle developer says the symptom resembles Sun's JDK bug #4908023 and suggests we try JDK 1.4.2_04.
We don't have a test case at this point. We're working on one since this is release critical now.
(Incident Review ID: 234589) 

EVALUATION ###@###.### 2004-03-01 May be the same problem as 4985384. ###@###.### 2004-03-02 Nope. It segv in GC in DefNewGeneration::copy_to_survivor_space(). May be it is the same as 4967900, 4964375. Passing to GC for further investigation. ---------------------------------------------------------------- It's dying walking the oop maps for an interpreter frame. The GC needs the oop maps to be right, else we are going to seg fault like that. If it doesn't take too long to get to the crash, try running a debug build with -XX:+VerifyBeforeGC -XX:+VerifyAfterGC and it should fail one of those verifications. If it fails a "before" verification then the oop maps are corrupt. If it fails an "after" then it's a GC bug. Running with those options will slow down collections considerably, so you will have to let it run for longer than you might be used to to get to the same point in the execution. ###@###.### 2004-03-02 ---------------------------------------------------------------- It fails while doing VerifyBeforeGC so the oop maps are corrupt. to debug, go to the test directory run "runtest". The vm crashes with -Xint too, it. ###@###.### 2004-03-05 Marvin, Does this exist with 1.5.0-b41 or greater?? If not, then an escalation report needs to be filed for this bug to get fixed in next 1.4.2_x release.. This bug is marked fixed but the evaluation doesn't say what was fixed. thanks. ###@###.### 2005-2-14 17:00:15 GMT This bug was fixed in 1.4.2_06 as a result of an escalation - you should be able to see the escalation by clicking on "escalations" tab in bugster. This bug is not in 1.5. CTE engineer has the fix. ###@###.### 2005-2-14 17:34:18 GMT

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_06 generic FIXED IN: 1.4.2_06 INTEGRATED IN: 1.4.2_06

WORK AROUND Name: wm7046 Date: 03/01/2004 N/A ======================================================================