SIGBUS Crash in void FastScanClosure::do_oop(oopDesc**)

SYNOPSIS
SIGBUS Crash in void FastScanClosure::do_oop(oopDesc**)

OPERATING SYSTEM(S)
Solaris 10

FULL JDK VERSION(S)
1.4.2_18-b06

PROBLEM DESCRIPTION
hs_err:-

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGBUS (0xa) at pc=0xfe8cdbb0, pid=17108, tid=3
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2_18-b06 mixed mode)
# Problematic frame:
# V [libjvm.so+0xcdbb0]
#

--------------- T H R E A D ---------------

Current thread (0x0011fc78): VMThread [id=3]

siginfo:si_signo=10, si_errno=0, si_code=1, si_addr=0x000006ad

Registers:
 O0=0x86a2ed30 O1=0x7e0da308 O2=0x0a3b17f8 O3=0x01340ab8
 O4=0x00000000 O5=0x00000004 O6=0xfbb7f4e8 O7=0xfe8cdbdc
 G1=0x00005000 G2=0x88c00000 G3=0x000004d0 G4=0x00051d8b
 G5=0x000006ad G6=0x00000000 G7=0xfdee0a00 Y=0x00000000
 PC=0xfe8cdbb0 nPC=0xfe8cdbb4


  Top of Stack: (sp=0xfbb7f4e8)
0xfbb7f4e8: 01340ac8 00000000 0000ffe0 6497fa28
0xfbb7f4f8: ea777cb0 fbb7f0d0 fbb7eca4 feda0000
0xfbb7f508: fbb7fabc 0a3b1838 fbb7f618 f9000214
0xfbb7f518: 0047aed8 fe95d05c fbb7f548 fed215fc
0xfbb7f528: 00000003 00000000 0fa1be00 fede84b8
0xfbb7f538: fbb7f608 fbb7fabc fbb7f608 f965c048
0xfbb7f548: fe8cdb8c fbb7fabc 0a3b1308 00000134
0xfbb7f558: 00000013 00000135 0000010a 0a3b1368

Instructions: (pc=0xfe8cdbb0)
0xfe8cdba0: c4 06 20 1c 80 a1 40 02 1a 48 00 1e 01 00 00 00
0xfe8cdbb0: c4 01 60 00 84 08 a0 03 80 a0 a0 03 32 40 00 07

Stack: [0xfbb00000,0xfbb80000), sp=0xfbb7f4e8, free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xcdbb0]
V [libjvm.so+0x521604]
V [libjvm.so+0x1a3950]
V [libjvm.so+0x2289dc]
V [libjvm.so+0x227b40]
V [libjvm.so+0x23bd28]
V [libjvm.so+0x233a50]
V [libjvm.so+0x23c5e4]
V [libjvm.so+0x23c2dc]
V [libjvm.so+0x230218]
V [libjvm.so+0x22fc38]
V [libjvm.so+0x2f3790]
V [libjvm.so+0x2f328c]
V [libjvm.so+0x4bd138]

VM_Operation (0x63bfa560): generation collection for allocation, mode: safepoint, requested by thread 0x04a3fe70


pstack:-
----------------- lwp# 3 / thread# 3 --------------------
 ff2cc674 _lwp_kill (6, 0, ff334f18, ff2abf30, ffffffff, 6) + 8
 ff24194c abort (0, 1, fecc3b84, eeb60, ff3333d8, 0) + 110
 fecbdb8c __1cCosFabort6Fi_v_ (1, fed859ad, 1, 80808080, ff0000, 80808080) + 54
 fed24278 __1cHVMErrorOreport_and_die6M_v_ (fed9bee0, fed9beef, fed9beff, fe8cdbb0, fbb7f468, fbb7f1b0) + 980
 fe9dae84 JVM_handle_solaris_signal (a, fe8cdbb0, fed854b1, 1, fbb7f1e8, fdee0a00) + a18
 ff2c8a94 __sighndlr (a, fbb7f468, fbb7f1b0, fe9da438, 0, 1) + c
 ff2bd140 call_user_handler (a, ffbffeff, c, 0, fdee0a00, fbb7f1b0) + 3b8
 ff2bd314 sigacthandler (a, fbb7f468, fbb7f1b0, 1340ab8, fdee0a00, 0) + 4c
 --- called from signal handler with signal 10 (SIGBUS) ---
 fe8cdbb0 __1cPFastScanClosureGdo_oop6MppnHoopDesc__v_ (fbb7fabc, a3b1838, fbb7f618, f9000214, 47aed8, fe95d05c) + 24
 fed215fc __1cLvframeArrayHoops_do6MpnKOopClosure__v_ (438, 14, 0, 1, 1, ff334f18) + 90
 fe9a3948 __1cKJavaThreadHoops_do6MpnKOopClosure__v_ (47b7a98, fbb7fabc, 0, 3f80, fe, 0) + 184
 fea289d4 __1cHThreadsHoops_do6FpnKOopClosure__v_ (fbb7fabc, fbb7fabc, 60000000, feda0000, ff334f18, ff335434) + 30
 fea27b38 __1cQGenCollectedHeapUprocess_strong_roots6Miiin0ATClassScanningOption_pnQOopsInGenClosure_3_v_ (feda0000, fbb7fabc, 1, 0, 1, fbb7fa98) + a4
 fea3bd20 __1cQDefNewGenerationHcollect6MiiIii_v_ (ca508, 0, 4c00, 4e98, fbb7fa98, fbb7fabc) + 400
 fea33a48 __1cQGenCollectedHeapNdo_collection6MiiIiiiri_v_ (a13da, feda0000, 1, fed6b5af, 0, feddfcc0) + 574
 fea3c5dc __1cbCTwoGenerationCollectorPolicyZsatisfy_failed_allocation6MIiiri_pnIHeapWord__ (ca3e8, 6, feddfcc0, 0, 63bfa57c, ffffff8c) + 19c
 fea3c2d4 __1cbAVM_GenCollectForAllocationEdoit6M_v_ (63bfa560, fe8ebecc, 47, feda0000, ddf38, fedeca80) + 8c
 fea30210 __1cMVM_OperationIevaluate6M_v_ (63bfa560, 4800, feda0000, 38800, 4d20a0, fe9e3c90) + 8c
 fea2fc30 __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_ (11fc78, 63bfa560, ff000000, ff000000, 5400, 57fc) + 84
 feaf3788 __1cIVMThreadEloop6M_v_ (4c00, 4800, 4880, 4800, 4804, 3c00) + 3e8
 feaf3284 __1cIVMThreadDrun6M_v_ (11fc78, 3, 40, 0, 40, 1) + 8c
 fecbd130 java_start (11fc78, fbb80000, 0, 0, fecbcffc, 1) + 134
 ff2c8968 _lwp_start (0, 0, 0, 0, 0, 0)
.
.
.
Other Threads:
=>0x0011fc78 VMThread [id=3]
  0x0012bc80 WatcherThread [id=12]

VM state:at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x00038838/0x00038868] Threads_lock - owner thread: 0x0011fc78
[0x00035078/0x00038bb8] Heap_lock - owner thread: 0x04a3fe70
.
.
.
VM Arguments: (stripped out most extraneous -D options)
jvm_args: -verbose:gc -Xms1792m -Xmx1792m -XX:PermSize=256M -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC -XX:-UseParNewGC -Xmn256m -XX:SurvivorRatio=12 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Ddefault.client.encoding=UTF-8 -Dclient.encoding.override=UTF-8 -XX:+HeapDumpOnCtrlBreak -XX:+HeapDumpOnOutOfMemoryError
Launcher Type: SUN_STANDARD


SUGGESTED FIX
None

OTHER INFORMATION
Similarity with existing Sunbugs: 6484364 (and therefore 6565138)
These Sunbugs share the same evaluation, although the evaluation was clearly more appropriate for 6565138 given that it partly depends on the observation that one of the executions employed XX:+UseBiasedLocking; not true of 6484364. Our situation is similar to 6484364 also in that this execution occurred with XX:-UseParNewGC.

Thereafter, 6565138 and its evaluation depends upon changes enacted by CR 6298299 which I gather that CR is not public - was related to changes with the BiasedLocking code of 5.0 and therefore is consistent with the posted evaluation. However, 6484364 and our crash (at 1.4.2, and hence without BiasedLocking support delivered with 5.0 or the changes of 6298299) are clearly similar, varying only in one frame of the stack where the same type of crash occurs: was 6484364 really a duplicate of 6565138; or is it a latent problem that has been harboured in the codebase for even longer, including 1.4.2 JDKs?