Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6344991

1.4.2 crash in ParNew method ParRootScanWithoutBarrierClosure::do_oop

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: P2 P2
    • None
    • 1.4.2_04
    • hotspot
    • gc
    • sparc
    • solaris_9

      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)

            chrisphi Chris Phillips
            cmassi Claudio Massi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: