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,
Stephen
----
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:
/net/cores.germany/cores/CA_36376145/core.20.11.01
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
newcore
This will start dbx with the needed libs and the correct jvm.
-----
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,
Stephen
----
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:
/net/cores.germany/cores/CA_36376145/core.20.11.01
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
newcore
This will start dbx with the needed libs and the correct jvm.
- duplicates
-
JDK-4645614 Hotspot crashes during GC in Scavenge::scavenge_oop_with_check()
- Resolved
- relates to
-
JDK-4501186 java vm 1.3.1-b24 crashes
- Closed
-
JDK-4546307 libjvm 1.3.1 Scavenge func SIGSEGV causes Weblogics Apps Server 6 SP2 to Abort
- Closed
-
JDK-4622693 HotSpot VM Error 11; Error ID: 4F530E43505002C4 01; jdk1.3.1_01 client mixed
- Closed