JDK-4767085 : volanotest failed with Mantis b03 -d64 after 4 days 20 hours
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic,sparc
  • Submitted: 2002-10-23
  • Updated: 2006-06-15
  • Resolved: 2006-06-15
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.2 1.4.2Fixed
Related Reports
Duplicate :  
JDK-4791463 - VolanoTest failed on solaris sparc after 63 hours with Mantis b09 in 64 bits mod
Relates :  
JDK-5090967 - SIGSEGV in ContiguousSpace::prepare_for_compaction(CompactPoint*)
Description
With Mantis b03, volanotest failed on jtgb4u2c1.sfbay after 4 days 20 hours
with -d64

# uname -a
SunOS jtgb4u2c1 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-60

# /usr/j2se_b03/bin/java -version  
java version "1.4.2-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b03)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b03, mixed mode)

Processes are still alive on the machine. I have saved core files under
/bt/VolanoTestrun.19757.-d64
in server process 29344, t@4 shows:
=>[1] ContiguousSpace::prepare_for_compaction(0x10018a090, 0xffffffff796010f8, 0x0, 0x200, 0xffffffff33d26428, 0x0), at 0xffffffff7d2b557c
  [2] Generation::prepare_for_compaction(0x100189f10, 0xffffffff796010f8, 0x0, 0x1, 0x0, 0x27150), at 0xffffffff7d2be33c
  [3] GenMarkSweep::mark_sweep_phase2(0x1, 0xffffffff79601218, 0x0, 0xffffffff7d3e1248, 0x10010ebb0, 0xffffffff79601060), at 0xffffffff7d3e1930
  [4] GenMarkSweep::invoke_at_safepoint(0x0, 0x9400, 0xb000, 0xb060, 0x9570, 0xffffffff79601260), at 0xffffffff7d3e12e0
  [5] OneContigSpaceCardGeneration::collect(0x100187c90, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7d2db694
  [6] GenCollectedHeap::do_collection(0x0, 0x0, 0x1, 0x0, 0xffffffff7d698000, 0xffffffff19300a70), at 0xffffffff7d2a8948
  [7] TwoGenerationCollectorPolicy::satisfy_failed_allocation(0x1001875e0, 0x5, 0x100187640, 0x3, 0xffffffff19300a70, 0xffffffff7d721e50), at 0xffffffff7d2b2338
  [8] VM_GenCollectForAllocation::doit(0xffffffff19300a38, 0x18, 0x0, 0x0, 0xffffffff7d2209c8, 0x0), at 0xffffffff7d2b2538
  [9] VM_Operation::evaluate(0xffffffff19300a38, 0x18, 0xffffffffffffffff, 0xffffffff7d743c18, 0xffffffff7d733d38, 0xffffffff79601880), at 0xffffffff7d2a6978
  [10] VMThread::evaluate_operation(0x1001e9520, 0xffffffff19300a38, 0x0, 0x10010f8b0, 0xffffffff7d340d10, 0x0), at 0xffffffff7d2a67f0
  [11] VMThread::loop(0x9800, 0x8800, 0x89f8, 0x8800, 0x8910, 0x7800), at 0xffffffff7d340d28
  [12] VMThread::run(0x1001e9520, 0xffffffff7f422000, 0xffffffff79601b58, 0x0, 0x0, 0x0), at 0xffffffff7d3405dc
  [13] _start(0x1001e9520, 0xffffffff7f424c00, 0x0, 0x1, 0xffffffff7f422000, 0x0), at 0xffffffff7d2c2e14


How to reproduce the problem: ( the problem is intermitten and it may take long
time to reproduce )
1. telnet to jtgb4u2c1.sfbay.sun.com
2. export JAVA_HOME=<your java home>
3. execute the script /net/jtgb4u4c.sfbay/export/sail8/bigapps/tests/runvtest.ksh -d64

###@###.### 2002-10-22
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: 1.4.2
14-06-2004
EVALUATION I was able to attach the process with dbx and grab the following info. I'm not really sure what is going on. The memory value for the klass pointer is bogus, but it looks like $g5 points at a reasonably valid object header. In either case, we know that the faulting line has to be around one of the prefetches in scan_and_forward (space.hpp). The call to size is also consistant with that. I can't really tell much more from this crash. 0xffffffff7d2b5558: prepare_for_compaction+0x0200: sllx %l0, 3, %g2 0xffffffff7d2b555c: prepare_for_compaction+0x0204: mov %o0, %l4 0xffffffff7d2b5560: prepare_for_compaction+0x0208: add %l3, %g2, %l3 0xffffffff7d2b5564: prepare_for_compaction+0x020c: mov %l3, %l6 0xffffffff7d2b5568: prepare_for_compaction+0x0210: ba prepare_for_compaction+0x15c 0xffffffff7d2b556c: prepare_for_compaction+0x0214: cmp %l3, %l2 0xffffffff7d2b5570: prepare_for_compaction+0x0218: mov %l3, %l1 0xffffffff7d2b5574: prepare_for_compaction+0x021c: prefetch [%l1 + %i3] , 2 0xffffffff7d2b5578: prepare_for_compaction+0x0220: ldx [%l1 + 0x8], %g5 <--- begin oop::size() invoke 0xffffffff7d2b557c: prepare_for_compaction+0x0224: ld [%g5 + 0x70], %g4 <--- Faulting instruction 0xffffffff7d2b5580: prepare_for_compaction+0x0228: cmp %g4, 0x0 0xffffffff7d2b5584: prepare_for_compaction+0x022c: bg,pt %icc,prepare_for_compaction+0x288 0xffffffff7d2b5588: prepare_for_compaction+0x0230: sra %g4, 0x0, %g2 0xffffffff7d2b558c: prepare_for_compaction+0x0234: bge,pn %icc,prepare_for_compaction+0x26c 0xffffffff7d2b5590: prepare_for_compaction+0x0238: mov -0x1, %g3 0xffffffff7d2b5594: prepare_for_compaction+0x023c: ld [%l1 + 0x10], %g2 0xffffffff7d2b5598: prepare_for_compaction+0x0240: sub %g3, %g4, %g3 0xffffffff7d2b559c: prepare_for_compaction+0x0244: sll %g2, %g3, %g2 0xffffffff7d2b55a0: prepare_for_compaction+0x0248: ld [%g5 + 0xd8], %g3 0xffffffff7d2b55a4: prepare_for_compaction+0x024c: add %g2, %g3, %g2 [ The oop we may have been looking at ] (/ws/on81-tools/SUNWspro/SC6.1/bin/../WS6U1/bin/sparcv9/dbx) print (void*)$i1 > (void *) $i1 = 0xffffffff796010f8 (/ws/on81-tools/SUNWspro/SC6.1/bin/../WS6U1/bin/sparcv9/dbx) fff796010f8 /16 < 0xffffffff796010f8: 0x00000001 0x00189f10 0x00000001 0x0018a090 0xffffffff79601108: 0xffffffff 0x33d26600 0x00000000 0x00000001 0xffffffff79601118: 0x00000001 0x7d3e1240 0x00000000 0x00000000 0xffffffff79601128: 0x00000000 0x00000000 0x00000000 0x00000000 [ The klass we may have been looking at. Note that the register and memory do not agree! ] (/ws/on81-tools/SUNWspro/SC6.1/bin/../WS6U1/bin/sparcv9/dbx) print (void*)$g5 > (void *) $g5 = 0xffffffff33d25108 (/ws/on81-tools/SUNWspro/SC6.1/bin/../WS6U1/bin/sparcv9/dbx) x (void*)$g5 /16 > 0xffffffff33d25108: 0x00000000 0x00000003 0xffffffff 0x33c014c0 0xffffffff33d25118: 0x000000a9 0x00000000 0xffffffff 0x33d25680 0xffffffff33d25128: 0xffffffff 0x33d27008 0xffffffff 0x33d26d08 0xffffffff33d25138: 0x00000000 0x00000000 0x0012d591 0x00000000 [ The size offset into the klass ] (/ws/on81-tools/SUNWspro/SC6.1/bin/../WS6U1/bin/sparcv9/dbx) fff33d25178 /16 < 0xffffffff33d25178: 0xffffffff 0x33c0e390 0xffffffff 0x33c04830 0xffffffff33d25188: 0xffffffff 0x33c04810 0xffffffff 0x33c02538 0xffffffff33d25198: 0xffffffff 0x33c02558 0xffffffff 0x33c02580 0xffffffff33d251a8: 0xffffffff 0x33c024c0 0xffffffff 0x33d25748 ###@###.### 2002-10-22 I cannot pursue further evaluation of this bug due to another 64-bit sparc bug which is cropping up in ~1 - 4 hours of run time. ###@###.### 2003-01-27 This is no longer showing up in testing, so I'm marking it fixed.
27-01-2003