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

java vm crashes in garbage collection



    • sparc
    • solaris_8


      This bug is openend on request of Stephen Fitch:
      Hi Peter, Torstenm

      to help us here in JPSE (CTE) we would like a new escalation
      logged on this issue that has come to light with Deutsche Bank.

      Please proceed to log a bug and a new escalation and enter it as
      soon as possible.

      Kind regards,


      This bug is a follow on to the bug 4501186 which is handled by escalation 532044.
      There we had 3 java vm crashes in Exception mark. Now we have a new situation as the vm seem to be crashed in a garbage collection.

      This is the stack trace:

      current thread: t@2
      =>[1] _libc_nanosleep(0x867f8500, 0x867f84f8, 0x0, 0xff339c18, 0x2000, 0x0), at 0xff3162cc
        [2] _liblwp_sleep(0x867fa000, 0xff339c18, 0xff33a254, 0xff336000, 0x1bab884, 0x3ff), at 0xff36c57c
        [3] os::message_box(0x867f91e8, 0xff043764, 0xff33a254, 0x1, 0xff383898, 0x184a34), at 0xfefa8338
        [4] os::handle_unexpected_exception(0x0, 0xb, 0xff0aae9c, 0xff0436f8, 0xff098000, 0x0), at 0xfefa6500
        [5] JVM_handle_solaris_signal(0x0, 0x0, 0x867f9490, 0xff098000, 0xb, 0x867f9748), at 0xfee074b0
        [6] __sighndlr(0xb, 0x867f9748, 0x867f9490, 0xfee074c8, 0x0, 0x0), at 0xff370824
        [7] call_user_handler(0xc, 0xfee074c8, 0x867f9490, 0x867f9748, 0xb, 0x0), at 0xff36db2c
        [8] sigacthandler(0xb, 0x867f9748, 0x867f9490, 0x86d9ed14, 0xff098000, 0x711f8), at 0xff36dce4
        ---- called from signal handler with signal 11 (SIGSEGV) ------
        [9] oopDesc::copy_to_survivor_space(0x878c6ef0, 0x0, 0x878c6ef0, 0x8, 0xff098000, 0x867f9824), at 0xfecb5530
        [10] Scavenge::scavenge_oop_with_check(0x62c7f8ec, 0x62c7f8ec, 0x867f9a70, 0x1479d0, 0x12, 0x80), at 0xfecdd77c
        [11] OopMapSet::all_do(0x867f9a60, 0xff0207a4, 0x867f9a70, 0xfecdd6fc, 0xffe0, 0x1), at 0xfed668a8
        [12] OopMapSet::oops_do(0x867f9a60, 0xfbcaf150, 0x867f9a70, 0xfecdd6fc, 0x0, 0x33158c), at 0xfed66a4c
        [13] frame::oops_do(0xfbcaf150, 0xfecdd6fc, 0x867f9a70, 0xff098000, 0x867f9a60, 0xfecdd6fc), at 0xfed36660
        [14] JavaThread::oops_do(0x0, 0xfecdd6fc, 0xff098000, 0xf7474e74, 0xf7474e74, 0xfecdd6fc), at 0xfed7aa44
        [15] Threads::oops_do(0xff098000, 0x1a415e8, 0xfecdd6fc, 0x20, 0x394e78, 0xfecdd6fc), at 0xfedf8040
        [16] Scavenge::invoke_at_safepoint(0xff1091e0, 0xff0adc24, 0xff0adc18, 0x0, 0xff10f8fc, 0xff1091d8), at 0xfee0d91c
        [17] VM_Operation::evaluate(0x6c47f420, 0xff0b0288, 0xcc, 0x867f9, 0xff098000, 0x867f9dc4), at 0xfed92d98
        [18] VMThread::evaluate_operation(0x17d1c0, 0x6c47f420, 0xff098000, 0xff0ad6b4, 0xff0a96c4, 0xff098000), at 0xfed92e3c
        [19] VMThread::loop(0x17d1c0, 0x6c47f420, 0x8, 0xff0b4bcc, 0xff0b4bc0, 0xff0b4bd0), at 0xfeecf4cc
        [20] VMThread::run(0xff098000, 0x17d1c0, 0x0, 0x0, 0x0, 0x0), at 0xfeecee58
        [21] _start(0xff098000, 0x867fa000, 0x0, 0x0, 0x0, 0x0), at 0xfee10aa8

      All information on this bug can be found on:


      ls -l
      total 3982974
      drwxrwxrwx 3 pmaier sun 512 Nov 21 10:45 ./
      drwxrwxrwx 19 pmaier sun 1024 Nov 20 14:14 ../
      -rw-rw-rw- 1 pmaier sun 1981014840 Nov 20 18:33 core8670
      -rw-rw-rw- 1 pmaier sun 3022 Nov 20 16:56 dbx-stack-trace
      -rw-rw-rw- 1 pmaier sun 607 Nov 20 15:59 email
      -rw-rw-rw- 1 pmaier sun 1089770 Nov 20 15:37 jvmcrash.log
      drwxr-xr-x 8 pmaier sun 512 Nov 21 10:45 new-libs/
      -rw-rw-rw- 1 pmaier sun 51181534 Nov 20 15:58 old_log.log.20011120104301
      -rw-rw-rw- 1 aa115221 staff 4926257 Nov 20 18:35 old_loglog20011120104301.gz

      core8670 is the corefile
      email shows the java startparameters:

      -server -verbose:gc -Xnoclassgc -XX:+PrintCompilation -Xbatch -XX:+ShowMessageBoxOnError -Xms1800m -Xmx1800m

      jvmcrash.log is a pstack/pmap/pflags

      old_log.log.20011120104301 is the logfile of the java process with print compilation outputs at the beginning and the starting gc and crash at the end.

      patches are accurate.

      java version is:

      java version "JPSE_1.3.1_20011012"
      Java(TM) 2 Runtime Environment, Standard Edition (build JPSE_1.3.1_20011012)
      Java HotSpot(TM) Client VM (build 1.3.1_02, mixed mode)

      This is a special version build by ###@###.### for escalation 532044.

      You can work on the core on our e10k domain:

      telnet srv167.germany
      login: eng
      pwd: test123

      start the script


      This will start dbx with the needed libs and the correct jvm.


        Issue Links



              sundar Sundararajan Athijegannathan
              pmaier Peter Maier (Inactive)
              0 Vote for this issue
              1 Start watching this issue