JDK-6344991 : 1.4.2 crash in ParNew method ParRootScanWithoutBarrierClosure::do_oop
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.2_04
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2005-11-02
  • Updated: 2014-02-27
  • Resolved: 2006-08-14
Related Reports
Relates :  
Relates :  
Description
The customer is running server jvm 1.4.2_04 bundled with AS7.1 on a Sol9 machine

$ ./asadmin version --verbose
    Sun Java System Application Server 7 2004Q2 (build A041434-314570)

Jvm options in use:
-Xms128m -Xmx256m -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SoftRefLRUPolicyMSPerMB=1 -Dsun.rmi.dgc.server.gcInterval=3600000

Below the native stack using dbx

t@15 (l@15) terminated by signal SEGV (Segmentation Fault)
0xfd8a19e0: do_oop+0x0038:	ld       [%l3], %l4
(dbx) regs
current thread: t@15
current frame:  [1]
g0-g3	 0x00000000 0x00004c00 0xe5000000 0x0000255c
g4-g7	 0x00000000 0x00000006 0x00000000 0xfdef1c00
o0-o3	 0xfca7f838 0x00000006 0xfd9b7e2c 0xfd970000
o4-o7	 0x00000001 0x00000000 0xfca7f600 0xfd8a19b0
l0-l3	 0xfd562d60 0xf8790b08 0xe4591960 0x000000e4
l4-l7	 0x00299570 0xfd970000 0xe9a6c4d0 0xfd970000
i0-i3	 0xfca7fc4c 0xdad7e6dc 0x0000000c 0x00000002
i4-i7	 0x00000013 0x004498fc 0xfca7f660 0xfd592c2c
y	 0x00000000
psr	 0xfe101004
pc	 0xfd8a19e0:do_oop+0x38	ld       [%l3], %l4
npc	 0xfd8a19e4:do_oop+0x3c	sethi    %hi(0x2400), %g2
(dbx) where -h -l 2000
current thread: t@15

=>[1] libjvm.so:ParRootScanWithoutBarrierClosure::do_oop(0xfca7fc4c, 0xdad7e6dc, 0xc, 0x2, 0x13, 0x4498fc), at 0xfd8a19e0 
  [2] libjvm.so:OopMapSet::all_do(0x10, 0x1e92520, 0xfca7f838, 0xfca7fc4c, 0xfd699590, 0xfd9b7460), at 0xfd592c2c 
  [3] libjvm.so:OopMapSet::oops_do(0xfca7f828, 0xf8790b08, 0xfca7f838, 0xfca7fc4c, 0x3debf4, 0xfd55a5bc), at 0xfd592dfc 
  [4] libjvm.so:frame::oops_do(0xfca7f828, 0xfca7fc4c, 0xfca7f838, 0x1, 0x1, 0x0), at 0xfd55a5f8 
  [5] libjvm.so:JavaThread::oops_do(0x16624b8, 0xfca7fc4c, 0x2, 0x0, 0x0, 0x0), at 0xfd5a1f7c 
  [6] libjvm.so:Threads::possibly_parallel_oops_do(0xfca7fc4c, 0xfca7fc4c, 0x7b739, 0x0, 0x0, 0x0), at 0xfd8dd30c 
  [7] libjvm.so:GenCollectedHeap::process_strong_roots(0xfd970000, 0xfca7fc4c, 0x1, 0x0, 0x1, 0xfca7fc28), at 0xfd625cf8 
  [8] libjvm.so:ParNewGenTask::work(0xfa67fa88, 0x0, 0x0, 0x4000, 0x4178, 0x1), at 0xfd8a1128 
  [9] libjvm.so:GangWorker::run(0x2968e8, 0xf, 0x40, 0x0, 0x40, 0x0), at 0xfd8fb990 
  [10] libjvm.so:_start(0x2968e8, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfd66575c 

core file address ranges:
  0x00010000 - 0x00010d3a (text)
  0x00020000 - 0x00022000 (data)
  0x00022000 - 0x03a1e000 (data)
  0xd7974000 - 0xd7980000 (data)
  ....

 l@13 LWP suspended in OopMapSet::update_register_map()
 l@14 LWP suspended in OopMapSet::all_do()
o>l@15 signal SIGSEGV in ParRootScanWithoutBarrierClosure::do_oop()
 l@16 LWP suspended in resource_allocate_bytes() 

We can see that the address used in register l3=0x000000e4 is too small, outside address space (appservd start at 0x00010000, and data from 0x00020000)

Comments
EVALUATION This bug is probably a dup of 6322757, but we have no testcase to verify.
27-04-2006

EVALUATION Please note there is a similar cr# 6322757... The simplified signature for this cr# (6344991) is: (SIGSEGV) in ParRootScanWithoutBarrierClosure::do_oop OopMapSet::all_do OopMapSet::oops_do frame::oops_do JavaThread::oops_do Threads::possibly_parallel_oops_do GenCollectedHeap::process_strong_roots ParNewGenTask::work GangWorker::run
10-11-2005