Investigation on JVM crash without core dump (by JIT compiler)
Hi, All
I posted "JVM crash without core dump due to CompilerThread1" couple months ago.
http://forum.java.sun.com/thread.jspa?threadID=5253434
I would like show what we found, and ask couple questions
1) The reason of JVM crash is "CompilerThread0/1 wanted to allocate more native memory and eventually exceeded the limit of 32-bit Linux (on Redhat, the limit of VIRT is 3G)
2) After we lower the heap size (to reduce process size) and added process size monitor (track process size every minute) and JIT compilation log (-XX:+PrintCompilation),
We found sometimes JVM process jumped more than 800M when compiling one method. with the following log
Total time for which application threads were stopped: 0.1997400 seconds
5828 xxx.xxx.SomeClass::someMethod (1507 bytes)
5828 COMPILE SKIPPED: out of nodes during split (not retryable)
549002.449: [GC [PSYoungGen: 517897K->28390K(551296K)] 942855K->453348K(1229952K), 0.0726350 secs]
if we saw "COMPILE SKIPPED: out of nodes during split (not retryable)", the process size of JVM (VIRT/RES) always jumped 800M~1000M, and sometimes the memory get reverted in 30mins to couple hours, and sometimes it lasted forever. (so before we have larger footprint, this jump will kill JVM, right now, if the jump lasts forever, any more allocation on top of it also can kill jvm (much rare))
3) This is definitely a bug of JVM, because
it only happened on server mode, not client mode
it is random, that method can be compiled success on other JVM or next restart (we have 20 JVMs)
the method is not that complicate, like 100 lines, (bigger method gets compiled success)
this only happen on PROD environment, we can't reproduce it locally or QA (the method is always compiled success)
It mostly like under some condition (maybe node space is not enough), to compile that method will trigger JVM trying to allocate much more native memory.
4) We are going to disable this method by ".hotspot_compiler" to fix it, right now we are using lower footprint, JVM dies rarely.
+To understand more about this, I have some questions about JIT compiling+
I saw same method are compiled more than once from JIT log, like the method caused our problem, it only happens on 2nd time compilation.
Is it that JIT compiler will recompile the method with deeper optimization level some time, and more optimization it uses, the more memory it requires?
(like gcc has -O2 -O3)
Thanks!
Neo
Today, one JVM crashed again, with
{Heap before gc invocations=4188:
PSYoungGen total 540864K, used 487958K [0x8ba50000, 0xb1250000, 0xb1250000)
eden space 467328K, 100% used [0x8ba50000,0xa82b0000,0xa82b0000)
from space 73536K, 28% used [0xa82b0000,0xa96d5850,0xaca80000)
to space 71680K, 0% used [0xacc50000,0xacc50000,0xb1250000)
ParOldGen total 1024000K, used 493477K [0x4d250000, 0x8ba50000, 0x8ba50000)
object space 1024000K, 48% used [0x4d250000,0x6b439610,0x8ba50000)
PSPermGen total 101760K, used 101240K [0x2d250000, 0x335b0000, 0x4d250000)
object space 101760K, 99% used [0x2d250000,0x3352e1f8,0x335b0000)
405290.711: [GC [PSYoungGen: 487958K->17397K(544192K)] 981435K->518248K(1568192K), 0.0769350 secs]
Heap after gc invocations=4188:
PSYoungGen total 544192K, used 17397K [0x8ba50000, 0xb1250000, 0xb1250000)
eden space 472512K, 0% used [0x8ba50000,0x8ba50000,0xa87c0000)
from space 71680K, 24% used [0xacc50000,0xadd4d480,0xb1250000)
to space 70208K, 0% used [0xa87c0000,0xa87c0000,0xacc50000)
ParOldGen total 1024000K, used 500851K [0x4d250000, 0x8ba50000, 0x8ba50000)
object space 1024000K, 48% used [0x4d250000,0x6bb6cf70,0x8ba50000)
PSPermGen total 101760K, used 101240K [0x2d250000, 0x335b0000, 0x4d250000)
object space 101760K, 99% used [0x2d250000,0x3352e1f8,0x335b0000)
Total time for which application threads were stopped: 0.0779620 seconds
Exception in thread "CompilerThread1" java.lang.OutOfMemoryError: requested 4522768 bytes for Chunk::new. Out of swap space?
Similar Messages
-
Help on JVM Crash with core dump on solaris - 1.5_17
Some times in my load test scenarios on sun os boxes JVM crashing with core dump. Here is some dump from the file
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGSEGV (0xb) at pc=0xfea07f40, pid=1564, tid=10
# Java VM: Java HotSpot(TM) Server VM (1.5.0_17-b04 mixed mode)
# Problematic frame:
# V [libjvm.so+0x207f40]
--------------- T H R E A D ---------------
Current thread (0x0014e220): JavaThread "CompilerThread1" daemon [_thread_in_native, id=10]
siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000000
Registers:
O0=0x00000010 O1=0x019c1960 O2=0x01e00ec0 O3=0x002bdc48
O4=0x01042c68 O5=0xc467eb4c O6=0xc467e330 O7=0x01042c68
G1=0x01e00ea0 G2=0xff014c94 G3=0x000000e6 G4=0x01c5a4e4
G5=0x01736e20 G6=0x00000000 G7=0xfb9e4200 Y=0x00000000
PC=0xfea07f40 nPC=0xfea07f44
--------------- S Y S T E M ---------------
OS: Solaris 10 5/08 s10s_u5wos_10 SPARC
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 24 March 2008
uname:SunOS 5.10 Generic_127127-11 sun4v (T2 libthread)
rlimit: STACK 8192k, CORE infinity, NOFILE 65536, AS infinity
load average:2.73 2.67 2.21
CPU:total 32 has_v8, has_v9, has_vis1, has_vis2, is_ultra3, is_sun4v, is_niagara1
Memory: 8k page, physical 8257536k(366576k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_17-b04) for solaris-sparc, built on Nov 10 2008 01:58:40 by unknown with unknown Workshop:0x550
Here is the stack dump of the kill quit thread
----------------- lwp# 10 / thread# 10 --------------------
ff2c5bf0 lwpkill (6, 0, ff2f2e10, ff2a8bd0, ffffffff, 6) + 8
ff2410f8 abort (7400, 1, 7c00, ad314, ff2f12d8, 0) + 110
fee7e58c __1cCosFabort6Fi_v_ (1, 0, ff013084, fefde000, 7d94, 7c00) + 58
fef0de48 __1cHVMErrorOreport_and_die6M_v_ (0, ff03a640, ff033ff4, 1, fee82c88, ff033ff4) + c84
fea74138 JVM_handle_solaris_signal (b, c467e2b0, c467dff8, 8000, ff032fa0, 14e220) + ab4
ff2c4b28 __sighndlr (b, c467e2b0, c467dff8, fea7364c, 0, 1) + c
ff2b9b00 call_user_handler (b, ffbffeff, c, 0, fb9e4200, c467dff8) + 3b8
fea07f40 __1cMPhaseChaitinFSplit6MI_I_ (c467ec2c, 0, 0, 3677ac, 398, c) + 3410
fea13c68 __1cMPhaseChaitinRRegister_Allocate6M_v_ (c467eb4c, e88, dc0, ff0137d8, c467fb14, 48d) + 720
fea17c64 __1cHCompileICode_Gen6M_v_ (c467f218, 9e0c, 9c00, fef56b15, 0, c467ec2c) + 2b0
fea7ff14 __1cHCompile2t5B6MpnFciEnv_pnKC2Compiler_pnIciMethod_ii_v_ (c467f218, 0, 346c8, 0, fef569b8, 0) + c08
fea75fb8 __1cKC2CompilerOcompile_method6MpnFciEnv_pnIciMethod_i_v_ (c467fb14, fef42a90, 1e40f58, 244, 346c8, d1800000) + b0
fea76b68 __1cNCompileBrokerZinvoke_compiler_on_method6FpnLCompileTask__v_ (908928, 14e7fc, 13c900, 14e220, fef57367, c467fb14) + 4cc
feb3357c __1cNCompileBrokerUcompiler_thread_loop6F_v_ (ff0330b8, 13c8a0, 14e220, c5e67700, 14e7f8, 0) + 44c
feadbd20 __1cKJavaThreadDrun6M_v_ (14e220, ff037040, 7820, 0, 7800, 9400) + 2b0
fee7e0a8 __1cG_start6Fpv_0_ (14e220, 61c, fefde000, 0, 5874, 5800) + 208
ff2c49fc lwpstart (0, 0, 0, 0, 0, 0)
Any idea on this dump, helps me a lot.
Thanks.[http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/crashes.html]
-
JRockit JVM Crash Without Dump
I am running Windows Server 2003 with WebLogic Server Express 8.1 SP 4 and JRockit 1.4.2_05. I have an administrative server and 2 managed servers running on the same physical server with about 60 web applications spread across both managed servers. The administrative server starts as a Windows Service and the managed servers are started by calling weblogic.admin from a batch job that runs on server start.
My issue is that the 2 java.exe processes representing the managed servers both terminate without explanation at the same time. There is no dump or error messages from Jrockit. The only related messages on the server mention that commnication with the managed servers was lost.
The 2 managed servers run at times for a period of days before crashing and at other times they will crash twice in 20 minutes.
I have attempted to use the -Djrockit.waitonerror parameter in order to get a dump when the JVM is shutting down, but the process just crashes without prompting for a debug dump.
I have opened a case with BEA, but at this point they are saying that without a dump on crash they are not going to be able to do much....
Anyone out there know of any way to force JRockit to perform a dump if the process is terminating? Anyone come across an issue like this before? I find it unusual that they would be die at the same time each and every time.
Any help would be greatly appreciated.
Thanks-
Rich PlattWhat have you done to make sure it's JRockit that is terminating
prematurely rather than the Java program? Those sound like exactly the
kinds of symptoms you'd get from a Java program doing System.exit(0).
//Johan
Richard Platt wrote:
I am running Windows Server 2003 with WebLogic Server Express 8.1 SP 4 and JRockit 1.4.2_05. I have an administrative server and 2 managed servers running on the same physical server with about 60 web applications spread across both managed servers. The administrative server starts as a Windows Service and the managed servers are started by calling weblogic.admin from a batch job that runs on server start.
My issue is that the 2 java.exe processes representing the managed servers both terminate without explanation at the same time. There is no dump or error messages from Jrockit. The only related messages on the server mention that commnication with the managed servers was lost.
The 2 managed servers run at times for a period of days before crashing and at other times they will crash twice in 20 minutes.
I have attempted to use the -Djrockit.waitonerror parameter in order to get a dump when the JVM is shutting down, but the process just crashes without prompting for a debug dump.
I have opened a case with BEA, but at this point they are saying that without a dump on crash they are not going to be able to do much....
Anyone out there know of any way to force JRockit to perform a dump if the process is terminating? Anyone come across an issue like this before? I find it unusual that they would be die at the same time each and every time.
Any help would be greatly appreciated.
Thanks-
Rich Platt -
Inetd service/program crashes with core dump in Solaris 8 zone/container
I have developed a service in C that is launched from inetd when something comes on a specific port.
When a connection is opened to the port a core dump is created in the same directory where the executable file is located.
If you run the same service program from the command line everything is working perfect.
This is running in a Solaris 8 zone/container on a Solaris 10 machine.
Everything is set correctly in /etc/inetd.conf and in /etc/services.
I have even stripped down the program to a hello world program that is just printing a string to the screen and it is still crashing with a core dump.
# ldd test_srv
/usr/lib/secure/s8_preload.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1
The same service is running on a Linux machine and on a Solaris 10 machine without zones/containers without any problems.
Can you please help me figure out what am I missing. Is there something specific with zones/containers that should be set / configured?
Do I have to set some specific env. variables to work in a Solaris 8 zone/container environment or is it something very simple that I'm missing?Could you please examine the truss log and advice what the problem is and how to fix it?
(some lines deleted)
bash-2.03# truss -f -p 18361 #### /usr/sbin/inetd -s -t &
18361: poll(0xFFBFF528, 53, -1) (sleeping...)
18361: poll(0xFFBFF528, 53, -1) = 1
18361: accept(63, 0xFFBFF870, 0xFFBFF914, 1) = 3
18361: sigprocmask(SIG_BLOCK, 0xFFBFF5F0, 0xFFBFF600) = 0
18361: lwp_sigtimedwait(0xFFBFF600, 0xFFBFF578, 0x00000010) = 0
18361: lwp_sigtimedwait(0xFFBFF568, 0xFFBFF728, 0x00000010) = 0
18361: fork() = 1921
1921: fork() (returning as child ...) = 18361
1921: sigprocmask(0, 0x00000000, 0xFFBFF600) = 0
18361: sigprocmask(0, 0x00000000, 0xFFBFF600) = 0
1921: lwp_sigtimedwait(0xFFBFF600, 0xFFBFF578, 0x00000010) = 0
18361: sigprocmask(SIG_SETMASK, 0xFFBFF5F0, 0xFFBFF600) = 0
18361: close(3) = 0
18361: sigprocmask(0, 0x00000000, 0xFFBFF600) = 0
1921: lwp_sigtimedwait(0xFFBFF668, 0xFFBFF528, 0x00000020) = 0
1921: sigaction(SIGHUP, 0xFFBFF528, 0xFFBFF500) = 0
18361: lwp_sigtimedwait(0xFFBFF568, 0xFFBFF5F0, 0x00000010) = 0
1921: lwp_sigtimedwait(0xFFBFF508, 0xFFBFF458, 0x00000010) = 0
18361: sigprocmask(SIG_SETMASK, 0xFFBFF5F0, 0xFFBFF600) = 0
1921: sigprocmask(SIG_SETMASK, 0xFFBFF5F0, 0xFFBFF600) = 0
1921: lwp_sigtimedwait(0xFFBFF600, 0xFFBFF578, 0x00000010) = 0
1921: lwp_sigtimedwait(0xFFBFF568, 0xFFBFF728, 0x00000010) = 0
1921: fcntl(3, F_DUP2FD, 0x00000000) = 0
1921: close(3) = 0
1921: fcntl(0, F_DUP2FD, 0x00000001) = 1
1921: fcntl(0, F_DUP2FD, 0x00000002) = 2
1921: open64("/etc/.name_service_door", O_RDONLY) = 3
1921: fcntl(3, F_SETFD, 0x00000001) = 0
1921: door_info(3, 0xFF0C2748) = 0
1921: door_call(3, 0xFFBFF278) = 0
1921: close(67) Err#9 EBADF
1921: close(66) Err#9 EBADF
1921: close(65) Err#9 EBADF
1921: close(64) Err#9 EBADF
1921: close(63) = 0
1921: close(62) = 0
1921: close(12) = 0
1921: close(11) = 0
1921: close(10) Err#9 EBADF
1921: close(9) Err#9 EBADF
1921: close(8) Err#9 EBADF
1921: close(7) Err#9 EBADF
1921: close(6) Err#9 EBADF
1921: close(5) Err#9 EBADF
1921: close(4) Err#9 EBADF
1921: setrlimit(RLIMIT_NOFILE, 0xFFBFFD20) = 0
1921: xenix(398872, 0xFFBFF5E4, 0x00000040) = 38
1921: execve("/tmp/srv/t_srv", 0x0008B5FC, 0xFFBFFDA0) argc = 0
1921: getuid() = 0 [0]
1921: resolvepath("/usr/lib/ld.so.1", "/usr/lib/ld.so.1", 1023) = 16
1921: open("/var/ld/ld.config", O_RDONLY) = 3
1921: fstat(3, 0xFFBFF5E8) = 0
1921: mmap(0x00000000, 148, PROT_READ, MAP_SHARED, 3, 0) = 0xFF3E0000
1921: close(3) = 0
1921: stat("/usr/lib/libc.so.1", 0xFFBFF648) = 0
1921: resolvepath("/usr/lib/libc.so.1", "/usr/lib/libc.so.1", 1023) = 18
1921: open("/usr/lib/libc.so.1", O_RDONLY) = 3
1921: mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xFF340000
1921: mmap(0x00000000, 802816, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON, -1, 0) = 0xFF200000
1921: mmap(0xFF200000, 703520, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF200000
1921: mmap(0xFF2BC000, 24772, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 704512) = 0xFF2BC000
1921: munmap(0xFF2AC000, 65536) = 0
1921: memcntl(0xFF200000, 113528, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
1921: close(3) = 0
1921: stat("/usr/lib/libdl.so.1", 0xFFBFF648) = 0
1921: resolvepath("/usr/lib/libdl.so.1", "/usr/lib/libdl.so.1", 1023) = 19
1921: open("/usr/lib/libdl.so.1", O_RDONLY) = 3
1921: mmap(0xFF340000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF340000
1921: mmap(0x00000000, 8192, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON, -1, 0) = 0xFF330000
1921: mmap(0xFF330000, 2638, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF330000
1921: close(3) = 0
1921: stat("/usr/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1", 0xFFBFF368) = 0
1921: resolvepath("/usr/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1", "/usr/platform/sun4u-us3/lib/libc_psr.so.1", 1023) = 41
1921: open("/usr/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1", O_RDONLY) = 3
1921: mmap(0xFF340000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF340000
1921: close(3) = 0
1921: mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF320000
1921: dup(0) = 3
1921: llseek(0, 0, SEEK_CUR) Err#29 ESPIPE
1921: close(0) = 0
1921: fcntl(3, F_DUP2FD, 0x00000000) = 0
1921: close(3) = 0
1921: dup(1) = 3
1921: close(1) = 0
1921: fcntl(3, F_DUP2FD, 0x00000001) = 1
1921: close(3) = 0
1921: dup(2) = 3
1921: close(2) = 0
1921: fcntl(3, F_DUP2FD, 0x00000002) = 2
1921: close(3) = 0
1921: sys#177(0x00000080, 0xFFBFFB7C, 0xFF3F0518, 0x00000000, 0xFF3C2EF8, 0xFF2C0284) = 0x00000000 [0xFFBFFB7C]
1921: sys#227(0x00000006, 0x00000000, 0x0001ADF0, 0xFF3F0518, 0xFF3C3C18, 0xFF3C2670) = 0x0000000C [0x00000000]
1921: sys#227(0x00000002, 0x0000000C, 0x0000000E, 0xFFBFFCAE, 0x00000002, 0xFF3C2670) = 0x00000002 [0x00000000]
1921: Incurred fault #6, FLTBOUNDS %pc = 0xFF232E2C
1921: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
1921: Received signal #11, SIGSEGV [default]
1921: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
1921: *** process killed ***
18361: Received signal #18, SIGCLD, in poll() [caught]
18361: siginfo: SIGCLD CLD_DUMPED pid=1921 status=0x000B
18361: poll(0xFFBFF528, 53, -1) Err#4 EINTR
18361: lwp_sigtimedwait(0xFFBFF218, 0xFFBFF140, 0x00000010) = 0
18361: lwp_sigtimedwait(0xFFBFF130, 0xFFBFF218, 0x00000010) = 0
18361: sigprocmask(0, 0x00000000, 0xFFBFEF28) = 0
18361: poll(0xFFBFF528, 53, -1) (sleeping...)Thank you in advance -
Webcenter crashing with core dump
Hi All,
Once in a while Webcenter(11.1.1.5) is crashing and generating core dump and the error message is same evertime. We tried to research on addPartialTriggerListeners and found this kind of behaviour is a bug in apache trinidad version 1.2.5-core and is fixed in 1.2.7-core. But the webcenter we are using as version 1.2.12. Also the issue seems to be comming from webcenter/adf framework itself as none of our code uses addPartialTriggerListeners.
Please help us resolve this issue as we are getting this issue in our production environment and we need to fix this asap.
# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) at pc=0xffffffff7318caf0, pid=19921, tid=149
# JRE version: 6.0_29-b11
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode solaris-sparc compressed oops)
*# Problematic frame:*
+*# J org.apache.myfaces.trinidadinternal.context.RequestContextImpl.addPartialTriggerListeners(Ljavax/faces/component/UIComponent;[Ljava/lang/String;)V*#+
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
--------------- T H R E A D ---------------
Current thread (0x00000001145ba000): JavaThread "[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_in_Java, id=149, stack(0xfffffffea6800000,0xfffffffea6900000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000
Registers:
G1=0xffffffff503d5098 G2=0x00000001145ba000 G3=0xffffffff73516254 G4=0x00000000000000d1
ThanksOracle Support has a thread and work around for this.
DocID 1514563.1
Applies to:
Oracle WebCenter Portal - Version 11.1.1.5.0 and later
Information in this document applies to any platform.
Purpose
Java HotSpot Virtual Machine, a core component of Oracle's Java SE platform, known to core dump (resulting in a server crash) while optimizing certain methods in Oracle WebCenter.
If you can switch to JRockit you can get around it also. Otherwise follow the note and setup the appropriate pre-compile excludes in your WC startup script. -
I tried to build latest Python sources with Sun C compiler on Solaris snv_145 (sparc or x86)
There is no issue to build the binary, but then Python's
harness runs it as: 'python -E ./setup.py build' it core dumps.
Actually, Python's version and Sun compiler versions are not essential.
I tried viariety of them, and all produce the same core dump.
I ran dbx with this and pinpointed the place:
At some moment python binary calls rlinit_terminal_io() from
open source readline.so library, which in turn invokes kernel's tgetent()
function from libcurses.so.2. That tgetent() function crashes on the
following line where cur_term is nil:
if (strcmp(cur_term->_term, name) == 0)
The top of crashed stack looks like this:
========================
t@1 (l@1) signal SEGV (no mapping at the fault address) in tgetent at line 65 in file "tgetent.c"
65 if (strcmp(cur_term->_term, name) == 0)
(dbx) print name
name = 0x8047a4d "sun-cmd"
(dbx) print cur_term
cur_term = (nil)
(dbx) where
current thread: t@1
=>[1] tgetent(buffer = 0x8786dd0 "", name = 0x8047a4d "sun-cmd"), line 65 in "tgetent.c"
[2] rlinit_terminal_io(terminal_name = 0x8047a4d "sun-cmd"), line 460 in "terminal.c"
[3] readline_initialize_everything(), line 1066 in "readline.c"
[4] rl_initialize(), line 968 in "readline.c"
[5] setup_readline(), line 884 in "readline.c"
[6] PyInit_readline(), line 1133 in "readline.c"
[7] PyImportLoadDynamicModule(name = 0x8747698 "readline", pathname = 0x8656e38 "build/lib.solaris-2.11-i86pc-3.2-pydebug/readline.so", fp = (nil)), line 57 in "importdl.c"
===================
May be to prevent this crash I need to define some
environment variable which ultimately will initialize 'cur_term' global?
Please advise.Please edit your post and use code tags when posting logs and error messages to the boards:
https://wiki.archlinux.org/index.php/Fo … s_and_Code
As to your errors, this is documented in the wiki:
https://wiki.archlinux.org/index.php/Pa … stem.22.21 -
LMS 4.21 - ConfigMgmtServer crashes with core-dump
Hi all,
in our environment
Solaris 10
LMS 4.21
from time to time the ConfigMgmtServer crashes/terminates with a core-dump because of SIGILL (Illegal Instruction).
Is this a known bug related to LMS 4.21, or do we have to tune java parameters (Xms and Xmx)?
Thanks for any feedback.
Lothar
Please find attached some core-file extracts:
** Core file status **
debugging core file of cwjava (32-bit) from hostname
file: /opt/CSCOpx/bin/cwjava
initial argv:
CSCO.ConfigMgmtServer -cw /opt/CSCOpx -cw:jre lib/jre -Xms64m -Xmx384m -Xss1024
threading model: multi-threaded
status: process terminated by SIGILL (Illegal Instruction)
** Thread stack($c) **
0xfbb6e5e8(e3c35808, 0, 2, f5f52298, 0, d86ff6b0)
0xfb805ab0(e344ec28, 0, e0c9f678, fb8171a0, 341a9, d86ff738)
0xfb805ab0(f3985628, b8, 0, fb8171a0, 0, d86ff830)
0xfb805868(e344be48, df73b240, 0, fb817580, 0, d86ff8b8)
0xfb805fd0(f3985628, df73ea00, 0, fb8176e0, 10000000, d86ff938)
0xfb805fd0(e344be60, df4312a0, 0, fb8176e0, 7ec659, d86ff9d0)
0xfb805fd0(d86fffa0, 408fc, 0, fb8176e0, f56d1ba0, d86ffa48)
0xfb80021c(d86ffb34, d86ffd98, a, df4327c0, fb80b440, d86ffcc8)
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallAr
guments_pnGThread__v_+0x210(fb8001c0, af2c00, 1, 1bcf3f0, df4327c0, d86ffd98)
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle
_4pnRJavaCallArguments_pnGThread__v_+0x130(d86ffd90, 1bcf3f4, fee6ebfc, 1bcf400
, d86ffcc0, af2c00)
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsym
bolHandle_5pnGThread__v_+0x6c(1bcf3f4, d86ffd8c, d86ffd88, d86ffd84, d86ffd80,
fee6ebfc)
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x168(df434b88, af2c00
, 54800, fee6ef34, fee6ebfc, fee6e8c0)
libjvm.so`__1cKJavaThreadRthread_main_inner6M_v_+0x48(af2c00, 7a2898, 61, 9,
fee1a000, 0)
libjvm.so`java_start+0x170(af2c00, 60, 87d, fee1a000, fed9994d, fee5b3a4)
libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0)
>>> Just opened a TAC-Case for this issue <<<Hi all,
TAC-Solution -> Upgrade to at least LMS 4.24, there are known issues with ConfigMgmtServer in LMS 4.21
Lothar -
Forms 11g frmcmp gives Aborted (core dumped) error while compiling pll
Hello
We've installed oracle forms 11.1.2 on our linux server and are now trying to recompile all form objects from our previous release (10g).
All forms compile without much problems, but some pll's (not all) fail with the error: Aborted (core dumped).
Is there any way to find out what might be happening? I don't seem to find any log about what is causing this problem.
Any input or ideas are more then welcome.
Regards
Johan
Edited by: vanvojo on Sep 12, 2012 10:57 PMI had the same problem on my development machine; I solved it by converting all pll files to pld files with the 10g reports compiler and convert them back to pll with the 11g reports compiler. I noticed that the problem is most likely to occur on libraries having a lot of other libraries attached which are not converted to 11g yet, so it also might be that you can solve the problem by changing the compile-order. But anyway the reports compiler solved this problem for me without ordering the compilation steps ;)
cheers -
Core dumps with 1.5.0_06-b05... any idea why?
I am trying to run 1.5.0_06-b05 with Tomcat 5.5.9, and the application keeps producing core dumps from the JVM after some period of use. The hs_err file says the following:
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGSEGV (0xb) at pc=0xfee32868, pid=17413, tid=10
# Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# V [libjvm.so+0x632868]
--------------- T H R E A D ---------------
Current thread (0x00148aa8): JavaThread "CompilerThread1" daemon [_thread_in_native, id=10]
siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000000
Registers:
O0=0x00000000 O1=0x001e2af0 O2=0x001e2ad0 O3=0xfe9130bc
O4=0x001e4140 O5=0x00000003 O6=0x7097e620 O7=0xfee3283c
G1=0x001e44bc G2=0xfeffe43c G3=0x001e4520 G4=0x00000001
G5=0xfec07fc8 G6=0x00000000 G7=0xff351200 Y=0x00000000
PC=0xfee32868 nPC=0xfee3286c
Top of Stack: (sp=0x7097e620)
0x7097e620: 001e4494 001e4118 fefbe000 7097e680
0x7097e630: 00000001 00000000 001e415c 00000000
0x7097e640: feffea58 7097ebdc 00000000 001e415c
0x7097e650: 7097ebdc 001e44f8 7097e690 fe8f887c
0x7097e660: 7097e688 7097e68c 7097e684 00000002
0x7097e670: 0121d230 00000000 00000000 7097ebdc
0x7097e680: 00000000 00000002 021c9458 00000000
0x7097e690: 00001000 7097ec04 fe90d5a4 ff001e84
Instructions: (pc=0xfee32868)
0xfee32858: 12 40 00 08 90 10 20 00 d2 02 a0 04 d0 02 60 08
0xfee32868: ca 02 20 00 c8 01 60 30 9f c1 00 00 01 00 00 00
Stack: [0x70900000,0x70980000), sp=0x7097e620, free space=505k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x632868]
V [libjvm.so+0xf8884]
V [libjvm.so+0x1e3ba0]
V [libjvm.so+0x27f9f4]
V [libjvm.so+0x282748]
V [libjvm.so+0x278700]
V [libjvm.so+0x2793bc]
V [libjvm.so+0x335f28]
V [libjvm.so+0x2de2a4]
V [libjvm.so+0x664248]
Current CompileTask:
opto:5496 s! com.sun.mail.imap.IMAPStore.protocolConnect(Ljava/lang/String;ILjava/lang/String;Ljava/lang/String;)Z (415 bytes)
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x00feec18 JavaThread "Thread-353085" daemon [_thread_in_native, id=407147]
0x006fe240 JavaThread "Thread-353060" daemon [_thread_in_native, id=407116]
0x016ebad0 JavaThread "Thread-351745" daemon [_thread_in_native, id=405360]
0x00a5ef78 JavaThread "Thread-346549" daemon [_thread_in_native, id=398309]
0x0047c168 JavaThread "Thread-296436" daemon [_thread_in_native, id=334376]
0x003c8a60 JavaThread "Thread-296431" daemon [_thread_in_native, id=334371]
0x00ef1138 JavaThread "Thread-290124" daemon [_thread_in_native, id=327269]
0x01974680 JavaThread "Thread-290066" daemon [_thread_in_native, id=327208]
0x0110bf00 JavaThread "Thread-290064" daemon [_thread_in_native, id=327206]
0x0120d890 JavaThread "Thread-273644" daemon [_thread_in_native, id=308308]
0x017d6110 JavaThread "http-8083-Processor3731" daemon [_thread_blocked, id=87638]
0x005b2478 JavaThread "http-8083-Processor3730" daemon [_thread_blocked, id=87637]
0x019e4320 JavaThread "http-8083-Processor3729" daemon [_thread_blocked, id=87636]
0x01091e80 JavaThread "http-8083-Processor3728" daemon [_thread_blocked, id=87635]
0x0196fa30 JavaThread "http-8083-Processor3727" daemon [_thread_blocked, id=87634]
0x00660b18 JavaThread "http-8083-Processor3726" daemon [_thread_blocked, id=87633]
0x009f9ba0 JavaThread "http-8083-Processor3725" daemon [_thread_blocked, id=87632]
0x0139b060 JavaThread "http-8083-Processor3724" daemon [_thread_blocked, id=87631]
0x00d4f760 JavaThread "http-8083-Processor3723" daemon [_thread_blocked, id=87630]
0x00ab73d8 JavaThread "http-8083-Processor3722" daemon [_thread_blocked, id=87629]
0x005895d8 JavaThread "http-8083-Processor3721" daemon [_thread_blocked, id=87628]
0x024632c0 JavaThread "http-8083-Processor3720" daemon [_thread_blocked, id=87627]
0x00b91378 JavaThread "http-8083-Processor3719" daemon [_thread_blocked, id=87626]
0x009361d8 JavaThread "http-8083-Processor3718" daemon [_thread_blocked, id=87625]
0x005b1278 JavaThread "http-8083-Processor3717" daemon [_thread_blocked, id=87623]
0x016dfa00 JavaThread "http-8083-Processor3716" daemon [_thread_blocked, id=87622]
0x006369b0 JavaThread "http-8083-Processor3715" daemon [_thread_blocked, id=87621]
0x01960708 JavaThread "http-8083-Processor3714" daemon [_thread_blocked, id=87620]
0x00ffe7c0 JavaThread "http-8083-Processor3713" daemon [_thread_blocked, id=87619]
0x01115038 JavaThread "http-8083-Processor3712" daemon [_thread_blocked, id=87618]
0x002b7a18 JavaThread "http-8083-Processor3711" daemon [_thread_blocked, id=87617]
0x007556f8 JavaThread "http-8083-Processor3710" daemon [_thread_blocked, id=87616]
0x013f6d18 JavaThread "http-8083-Processor3709" daemon [_thread_blocked, id=87615]
0x0112b4d8 JavaThread "http-8083-Processor3708" daemon [_thread_blocked, id=87614]
0x00501d50 JavaThread "http-8083-Processor3707" daemon [_thread_blocked, id=87613]
0x005eda70 JavaThread "http-8083-Processor3706" daemon [_thread_blocked, id=87612]
0x00226d90 JavaThread "http-8083-Processor3705" daemon [_thread_blocked, id=87611]
0x00e788e8 JavaThread "http-8083-Processor3704" daemon [_thread_blocked, id=87610]
0x024729f0 JavaThread "http-8083-Processor3703" daemon [_thread_blocked, id=87608]
0x02447798 JavaThread "http-8083-Processor3702" daemon [_thread_blocked, id=87607]
0x00c61780 JavaThread "http-8083-Processor3701" daemon [_thread_blocked, id=87606]
0x004d6228 JavaThread "http-8083-Processor3700" daemon [_thread_blocked, id=87605]
0x012348f8 JavaThread "http-8083-Processor3699" daemon [_thread_blocked, id=87604]
0x010ebf10 JavaThread "http-8083-Processor3698" daemon [_thread_blocked, id=87603]
0x01651848 JavaThread "http-8083-Processor3697" daemon [_thread_blocked, id=87602]
0x00eae520 JavaThread "http-8083-Processor3696" daemon [_thread_blocked, id=87601]
0x0124ce68 JavaThread "http-8083-Processor3695" daemon [_thread_blocked, id=87600]
0x0190d170 JavaThread "http-8083-Processor3694" daemon [_thread_blocked, id=87599]
0x00c5b5c0 JavaThread "http-8083-Processor3693" daemon [_thread_blocked, id=87598]
0x00ffc9a8 JavaThread "http-8083-Processor3692" daemon [_thread_blocked, id=87597]
0x010602f8 JavaThread "http-8083-Processor3691" daemon [_thread_blocked, id=87596]
0x00c4c580 JavaThread "http-8083-Processor3690" daemon [_thread_blocked, id=87595]
0x01381190 JavaThread "http-8083-Processor3689" daemon [_thread_blocked, id=87594]
0x019a3e58 JavaThread "http-8083-Processor3688" daemon [_thread_blocked, id=87593]
0x0199a7a8 JavaThread "http-8083-Processor3687" daemon [_thread_blocked, id=87592]
0x01116db8 JavaThread "http-8083-Processor3686" daemon [_thread_blocked, id=87591]
0x019247e0 JavaThread "http-8083-Processor3685" daemon [_thread_blocked, id=87590]
0x018fc608 JavaThread "http-8083-Processor3684" daemon [_thread_blocked, id=87589]
0x014ce6c0 JavaThread "http-8083-Processor3683" daemon [_thread_blocked, id=87588]
0x004900a0 JavaThread "http-8083-Processor3682" daemon [_thread_blocked, id=87587]
0x00daaf88 JavaThread "http-8083-Processor3681" daemon [_thread_blocked, id=87514]
0x0117f358 JavaThread "http-8083-Processor3680" daemon [_thread_blocked, id=87513]
0x0110fc60 JavaThread "http-8083-Processor3677" daemon [_thread_blocked, id=87510]
0x015fc320 JavaThread "http-8083-Processor3676" daemon [_thread_blocked, id=87509]
0x00e93b40 JavaThread "http-8083-Processor3675" daemon [_thread_blocked, id=87508]
0x00d604d0 JavaThread "http-8083-Processor3674" daemon [_thread_blocked, id=87507]
0x00ff3ba0 JavaThread "http-8083-Processor3673" daemon [_thread_blocked, id=87506]
0x00d61dc0 JavaThread "http-8083-Processor3670" daemon [_thread_in_native, id=87503]
0x01969e78 JavaThread "http-8083-Processor3669" daemon [_thread_blocked, id=87502]
0x007c3820 JavaThread "http-8083-Processor3667" daemon [_thread_blocked, id=87500]
0x007ecb48 JavaThread "http-8083-Processor3665" daemon [_thread_blocked, id=87498]
0x004e8710 JavaThread "http-8083-Processor3664" daemon [_thread_blocked, id=87497]
0x0090bfc8 JavaThread "http-8083-Processor3663" daemon [_thread_blocked, id=87496]
0x011102b8 JavaThread "http-8083-Processor3662" daemon [_thread_blocked, id=87495]
0x00ff4738 JavaThread "http-8083-Processor3661" daemon [_thread_in_native, id=87494]
0x004d9940 JavaThread "http-8083-Processor3660" daemon [_thread_blocked, id=87493]
0x00a56798 JavaThread "http-8083-Processor3657" daemon [_thread_blocked, id=87490]
0x0011b318 JavaThread "http-8083-Processor3656" daemon [_thread_blocked, id=87489]
0x00c8bc68 JavaThread "http-8083-Processor3655" daemon [_thread_blocked, id=87488]
0x011a4d28 JavaThread "http-8083-Processor3654" daemon [_thread_blocked, id=87487]
0x01063680 JavaThread "http-8083-Processor3653" daemon [_thread_blocked, id=87486]
0x0195d108 JavaThread "http-8083-Processor3652" daemon [_thread_blocked, id=87485]
0x018da648 JavaThread "http-8083-Processor3651" daemon [_thread_blocked, id=87484]
0x005f45f0 JavaThread "http-8083-Processor3650" daemon [_thread_blocked, id=87483]
0x013cfa08 JavaThread "http-8083-Processor3649" daemon [_thread_blocked, id=87482]
0x00667d30 JavaThread "http-8083-Processor3648" daemon [_thread_blocked, id=87481]
0x01d47740 JavaThread "http-8083-Processor3647" daemon [_thread_blocked, id=87480]
0x01251628 JavaThread "http-8083-Processor3646" daemon [_thread_blocked, id=87479]
0x005769d8 JavaThread "http-8083-Processor3645" daemon [_thread_blocked, id=87478]
0x016c1798 JavaThread "http-8083-Processor3644" daemon [_thread_blocked, id=87477]
0x00ef6208 JavaThread "http-8083-Processor3643" daemon [_thread_blocked, id=87476]
0x00221b60 JavaThread "http-8083-Processor3642" daemon [_thread_blocked, id=87475]
0x016a2b88 JavaThread "http-8083-Processor3641" daemon [_thread_blocked, id=87474]
0x0198dc20 JavaThread "http-8083-Processor3640" daemon [_thread_blocked, id=87473]
0x00e61ff0 JavaThread "http-8083-Processor3639" daemon [_thread_blocked, id=87472]
0x00957df0 JavaThread "http-8083-Processor3638" daemon [_thread_blocked, id=87471]
0x011a8df0 JavaThread "http-8083-Processor3637" daemon [_thread_blocked, id=87470]
0x0059d3a0 JavaThread "http-8083-Processor3636" daemon [_thread_blocked, id=87469]
0x0124b068 JavaThread "http-8083-Processor3635" daemon [_thread_blocked, id=87468]
0x0238a5b0 JavaThread "http-8083-Processor3634" daemon [_thread_blocked, id=87467]
0x00a61a60 JavaThread "http-8083-Processor3633" daemon [_thread_blocked, id=87466]
0x019db810 JavaThread "http-8083-Processor3632" daemon [_thread_blocked, id=87465]
0x0199f968 JavaThread "http-8083-Processor3605" daemon [_thread_in_vm, id=87339]
0x019cac68 JavaThread "http-8083-Processor3596" daemon [_thread_blocked, id=87330]
0x0075d8a0 JavaThread "http-8083-Processor3586" daemon [_thread_blocked, id=87320]
0x0120f898 JavaThread "http-8083-Processor3585" daemon [_thread_blocked, id=87319]
0x00e6fcc0 JavaThread "http-8083-Processor3577" daemon [_thread_blocked, id=76622]
0x00ab1330 JavaThread "http-8083-Processor3528" daemon [_thread_blocked, id=76496]
0x01650d58 JavaThread "Thread-68062" daemon [_thread_in_native, id=73772]
0x0199b8e0 JavaThread "http-8083-Processor2576" daemon [_thread_blocked, id=64785]
0x01993158 JavaThread "http-8083-Processor2565" daemon [_thread_blocked, id=64774]
0x01409740 JavaThread "http-8083-Processor1700" daemon [_thread_blocked, id=58821]
0x00934000 JavaThread "MS UI IMAP Connection Reaper" daemon [_thread_blocked, id=100]
0x01812260 JavaThread "Thread-60" daemon [_thread_blocked, id=74]
0x00ebf9b8 JavaThread "Directory Cleaner Thread" daemon [_thread_blocked, id=73]
0x014895f0 JavaThread "TimerDirContext.TimerWatcher" daemon [_thread_blocked, id=71]
0x0161c7a0 JavaThread "MultiThreadedHttpConnectionManager cleanup" daemon [_thread_blocked, id=70]
0x00ee4988 JavaThread "RequestWatcher" daemon [_thread_blocked, id=69]
0x014eb550 JavaThread "http-8083-Monitor" [_thread_blocked, id=68]
0x0075c0e0 JavaThread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon [_thread_blocked, id=17]
0x00e1f870 JavaThread "JspRuntimeContext[ROOT]" daemon [_thread_blocked, id=16]
0x01636a40 JavaThread "Thread-2" [_thread_blocked, id=15]
0x0116f510 JavaThread "CronDaemon" daemon [_thread_blocked, id=14]
0x018cd3b0 JavaThread "JspRuntimeContext[WebRoot]" daemon [_thread_blocked, id=13]
0x0014a360 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=11]
=>0x00148aa8 JavaThread "CompilerThread1" daemon [_thread_in_native, id=10]
0x00147210 JavaThread "CompilerThread0" daemon [_thread_blocked, id=9]
0x001463a0 JavaThread "AdapterThread" daemon [_thread_blocked, id=8]
0x00145598 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7]
0x00139308 JavaThread "Finalizer" daemon [_thread_blocked, id=6]
0x00138dc8 JavaThread "Reference Handler" daemon [_thread_blocked, id=5]
0x00036c50 JavaThread "main" [_thread_in_native, id=1]
Other Threads:
0x00136ce8 VMThread [id=4]
0x0014b5e8 WatcherThread [id=12]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
PSYoungGen total 756672K, used 559590K [0xc6c00000, 0xf8c00000, 0xf8c00000)
eden space 713472K, 72% used [0xc6c00000,0xe6452e18,0xf24c0000)
from space 43200K, 99% used [0xf24c0000,0xf4ee6c38,0xf4ef0000)
to space 54208K, 0% used [0xf5710000,0xf5710000,0xf8c00000)
PSOldGen total 262144K, used 182087K [0x78c00000, 0x88c00000, 0xc6c00000)
object space 262144K, 69% used [0x78c00000,0x83dd1e78,0x88c00000)
PSPermGen total 61440K, used 52943K [0x70c00000, 0x74800000, 0x78c00000)
object space 61440K, 86% used [0x70c00000,0x73fb3f98,0x74800000)
Dynamic libraries:
0x00010000 /ps/jdk1.5.0_06/bin/java
0xff370000 /usr/lib/libthread.so.1
0xff3fa000 /usr/lib/libdl.so.1
0xff280000 /usr/lib/libc.so.1
0xff3a0000 /usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
0xfe800000 /ps/jdk1.5.0_06/jre/lib/sparc/server/libjvm.so
0xff250000 /usr/lib/libsocket.so.1
0xff230000 /usr/lib/libsched.so.1
0xff200000 /usr/lib/libCrun.so.1
0xff1b0000 /usr/lib/libm.so.1
0xff080000 /usr/lib/libnsl.so.1
0xff180000 /usr/lib/libmp.so.2
0xff060000 /ps/jdk1.5.0_06/jre/lib/sparc/native_threads/libhpi.so
0xfe7d0000 /ps/jdk1.5.0_06/jre/lib/sparc/libverify.so
0xfe790000 /ps/jdk1.5.0_06/jre/lib/sparc/libjava.so
0xfe760000 /ps/jdk1.5.0_06/jre/lib/sparc/libzip.so
0xf8dd0000 /ps/jdk1.5.0_06/jre/lib/sparc/libnet.so
0x6e800000 /ps/Webmail/WebRoot/WEB-INF/cplib/libcp_pabclient_native.so.solaris
0xf8cb0000 /usr/lib/libpam.so.1
0xf8c90000 /usr/lib/librt.so.1
0xf8c70000 /usr/lib/libpthread.so.1
0xf8c40000 /usr/lib/libcmd.so.1
0x6fbf0000 /usr/lib/libaio.so.1
0x6fbd0000 /usr/lib/libmd5.so.1
VM Arguments:
jvm_args: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/ps/tomcat/conf/logging.properties -Xmx2048m -XX:+UseParallelGC -Dsun.rmi.dgc.server.gcInterval=Long.MAX_VALUE -Dsun.rmi.dgc.client.gcInterval=Long.MAX_VALUE -XX:NewSize=800m -XX:MaxNewSize=800m -XX:SurvivorRatio=8 -XX:+MaxFDLimit -XX:SoftRefLRUPolicyMSPerMB=800 -XX:MaxPermSize=128m -Djava.endorsed.dirs=/ps/tomcat/common/endorsed -Dcatalina.base=/ps/tomcat -Dcatalina.home=/ps/tomcat -Djava.io.tmpdir=/ps/tomcat/temp
java_command: org.apache.catalina.startup.Bootstrap start
Launcher Type: SUN_STANDARD
Environment Variables:
JAVA_HOME=/ps/java
PATH=/usr/bin:/usr/sbin:/usr/ccs/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/usr/sbin:/usr/bin
LD_LIBRARY_PATH=/ps/jdk1.5.0_06/jre/lib/sparc/server:/ps/jdk1.5.0_06/jre/lib/sparc:/ps/jdk1.5.0_06/jre/../lib/sparc:/ps/Webmail/WebRoot/WEB-INF/cplib:
SHELL=/sbin/sh
HOSTTYPE=sun4
OSTYPE=solaris
MACHTYPE=sparc
Signal Handlers:
SIGSEGV: [libjvm.so+0x6f0ca8], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGBUS: [libjvm.so+0x6f0ca8], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGFPE: [libjvm.so+0x275d94], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGPIPE: [libjvm.so+0x275d94], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGILL: [libjvm.so+0x275d94], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGUSR1: [libjvm.so+0x666744], sa_mask[0]=0x00000000, sa_flags=0x00000008
SIGUSR2: [libjvm.so+0x275d94], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGHUP: [libjvm.so+0x665424], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGQUIT: [libjvm.so+0x665424], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGTERM: [libjvm.so+0x665424], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
--------------- S Y S T E M ---------------
OS: Solaris 9 9/04 s9s_u7wos_09 SPARC
Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 29 June 2004
uname:SunOS 5.9 Generic_118558-23 sun4u (T2 libthread)
rlimit: STACK 8192k, CORE infinity, NOFILE 65536, AS infinity
load average:0.07 0.21 0.20
CPU:total 2 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
Memory: 8k page, physical 8388608k(5653656k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_06-b05) for solaris-sparc, built on Nov 10 2005 11:24:16 by unknown with unknown Workshop:0x550
I am wandering if anyone can shed some light on the following lines:
Current CompileTask:
opto:5496 s! com.sun.mail.imap.IMAPStore.protocolConnect(Ljava/lang/String;ILjava/lang/String;Ljava/lang/String;)Z (415 bytes)
What exactly is meant by the Current Compile Task? This is a runtime environment, so I don't understand why classes in the com.sun.mail package would need to be compiled at this time.
Thanks,
Filip
FilipThe JVM has as just-in-time (JIT) compiler, which translates bytecodes into machine instructions for frequently used methods. The Current Compile Task is the method being compiled by the HotSpot JIT when the crash occurred.
The crash is most likely bug 6346871, which was fixed in 1.5.0_07. Your problem should go away if you migrate to that version. -
Snmpdemo core dump when sending traps
Hi,
I am investigating the SEA SNMP toolkit on Solaris x86 7 & 8. I applied the recommended patches on both of my systems. Everything worked fine except the traps.
I modified the mib_demo.txt by adding a test trap definition:
myTestTrap TRAP-TYPE
ENTERPRISE demo
VARIABLES {
demoEntryInteger
DESCRIPTION "This is a test trap."
::= 2
Then I used mibcodgen to generate the code, and modified agent_loop() in snmpdemo_appl.c to let it send the trap in every agent_loop. It compiled okay, but it core dumped when it ran into SSASendTrap3(...) in snmpdemotrap.c. The _SSASendTrap3 looks like a SDK function that I have no clue how it processes inside.
I noticed if I change "demoEntryInteger" into "demoInteger" - to change the variable(s) from table attribute(s) to non-table attribute(s), and followed the same build process, the snmpdemod worked fine - I was able to get the traps on the destination host without core dump.
I discovered this problem several weeks ago on Solaris 7, and now I found the same on Solaris 8.
I think it is quite common for a subagent to bind some variables to the enterprise-specific traps. And the variables can be attributes of a talbe entry. And this is exactly the case of the subagent which I am going to work on.
Any clue? Could it be a SDK defect? Or is there any newer patch which has already fixed this problem?
Or any way to hack _SSASendTrap3 so that I can get around it?
Thanks a lot!
WenIt works by using _SSASendTrap4( char *, IndexType * )
instead of _SSASendTrap3( char * ).How?
_SSASendTrap(char *, IndexType *) long-jumps into oblivion whenever I try it. Can someone please provide an example? -
Core dump with stlport4 and string pointers
Hello,
I am porting from SGI Irix to Sun Solaris, using OS 8 and Sun Studio 8. The program we are porting is very very large. We've compiled all code, but now are getting core dumps on several of the executables. We have traced one of the core dumps to a function that deals with string manipulation/string pointers. We wrote a very simple test program that re-produces the problem.
#include <string>
#include <iostream>
void test(char* m)
std::cout << m << " in test before";
m[0] = 'z';
std::cout << m << " in test after";
void main(void)
char* temp = new char[10];
temp = "abcd";
std::cout << temp << " before test";
test(temp);
std::cout << temp << " after test";
We get the following output:
abcd before test
abcd in test before
Segmentation fault (core dumped)
The code compiles and runs fine on the SGI Irix system. What am I doing wrong?
Thanks,
Bob1) The signature of "main" is wrong. It must be 'int
main(int, char **)'Not quite. The signatures
int main()
int main(void)
are also allowed. (C++ standard, section 3.6.1 Main function)
A "void" return type on main is not standard, but Sun C++ allows it with a warning. Such a version of main does not return a predictable value to the program that invoked it (usually the shell).
It seems as if the intent of the program is to
allocate a new string with the contents "abcd".
Instead, you allocate a buffer, and then overwrite the
pointer to that buffer with a pointer to a string
constant, to which you then attempt to write.Right. By default, the C++ compiler allocates string literals to read-only memory, to catch mistakes like this. The compiler has an option to store literal strings in read-write memory, but we recommend against using the option, since you should not ever want to modify a literal string.
I am curious why the compiler doesn't complain about
the assignment in main - to my eyes it looks like it
should be complaining that you are assigning a const
char * to a char *The compiler emits a warning about the assignment.
Such code is allowed but deprecated in the C++ standard, because of the deprecated conversion of "array of const char" to char* (section 4.2 Array-to-pointer conversion). -
We have a weblogic 9 cluster where a node crash/shutdown with no trace. Sometimes its node 2 and sometimes node 3, but not at the same time.
We can't find any core dump, hs_err_pid or any stracktrace in the logs or std out/err.
Specifying where hs_err files goes with -XX:ErrorFile should not be necessary as it should write in current directory or if not possible due to permissions etc, in the OS tmp dir.
Are there any Weblogic specific JVM or system property we can specify to force some kind of trace when the process just seem to crash?
We see this in the log from time to time, perhaps its related:
<2012-jun-08 kl 13:53 CEST> <Error> <Security> <BEA-090060> <The AccessDecision class "weblogic.security.providers.realmadapter.AuthorizationProviderImpl" returned an error: java.lang.SecurityException: Realm Adapter ACL Mapping Failed.>
Can the above hide a possible out of memory error trace to appear in the logs?
SERVER: Weblogic 9.2.3 with some additional patches (and compatibility mode)
OS: HP-UX B.11.23 U ia64
JAVA: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0.20-_28_apr_2010_03_15)
Java HotSpot(TM) Server VM (build 1.5.0.20 jinteg:04.28.10-02:28 IA64, mixed mode)http://docs.oracle.com/cd/B28359_01/java.111/b31224/instclnt.htm gives some info about the used libraries (libocijdbc11.so)
Could you check the environment variable - http://docs.oracle.com/cd/B28359_01/java.111/b31224/getsta.htm#i1005378
"On Sun Solaris or Linux, set the LD_LIBRARY_PATH environment variable as follows:
ORACLE_HOME/lib
This directory contains the libocijdbc11.so shared object library.
Note:
If you are running a 32-bit Java Virtual Machine (JVM) against a 64-bit client or database, then you must also add ORACLE_HOME/lib32 to the LD_LIBRARY_PATH environment variable." -
JVM crashes with " ErrOut:Abort - core dumped "
Hi
I am using Sun Sparc server.when running my installer i am getting an error
ErrOut:
Abort - core dumped
Server Version:
bash-2.03$ isainfo
sparcv9 sparc
bash-2.03$ isainfo -v
64-bit sparcv9 applications
32-bit sparc applications
bash-2.03$ isainfo -k
sparcv9
bash-2.03$
I installed jdk 1.4.2_16 java version.
Please help in solving this issue... We are unable to go with Installation
==================================================
I+In LOG FILE:+
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0xEC10E15C
Function=[Unknown. Nearest: Java_sun_awt_font_NativeFontWrapper_registerFonts+0x346C]
Library=/tmp/SIEBEL/isjAAABfaqsI/lib/sparc/libfontmanager.so
Current Java thread:
at sun.awt.font.NativeFontWrapper.registerFonts(Native Method)
- locked <f6468460> (a java.lang.Class)
at sun.java2d.SunGraphicsEnvironment.addPathFonts(SunGraphicsEnvironment.java:736)
at sun.java2d.SunGraphicsEnvironment.registerFonts(SunGraphicsEnvironment.java:590)
at sun.java2d.SunGraphicsEnvironment.access$100(SunGraphicsEnvironment.java:49)
at sun.java2d.SunGraphicsEnvironment$2.run(SunGraphicsEnvironment.java:209)
at java.security.AccessController.doPrivileged(Native Method)
at sun.java2d.SunGraphicsEnvironment.loadFonts(SunGraphicsEnvironment.java:203)
- locked <ee39ad38> (a sun.awt.X11GraphicsEnvironment)
at sun.java2d.SunGraphicsEnvironment.initTerminalNames(SunGraphicsEnvironment.java:1029)
at sun.java2d.SunGraphicsEnvironment.initCompositeFonts(SunGraphicsEnvironment.java:795)
at sun.java2d.SunGraphicsEnvironment.access$200(SunGraphicsEnvironment.java:49)
at sun.java2d.SunGraphicsEnvironment$1.run(SunGraphicsEnvironment.java:160)
at java.security.AccessController.doPrivileged(Native Method)
at sun.java2d.SunGraphicsEnvironment.<init>(SunGraphicsEnvironment.java:78)
at sun.awt.X11GraphicsEnvironment.<init>(X11GraphicsEnvironment.java:150)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:306)
at java.lang.Class.newInstance(Class.java:259)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:62)
- locked <f641dc98> (a java.lang.Class)
at java.awt.Font.initializeFont(Font.java:309)
at java.awt.Font.<init>(Font.java:345)
at javax.swing.plaf.FontUIResource.<init>(FontUIResource.java:36)
at com.sun.java.swing.plaf.motif.MotifLookAndFeel.initComponentDefaults(MotifLookAndFeel.java:181)
at javax.swing.plaf.basic.BasicLookAndFeel.getDefaults(BasicLookAndFeel.java:81)
at javax.swing.UIManager.setLookAndFeel(UIManager.java:394)
at javax.swing.UIManager.setLookAndFeel(UIManager.java:424)
at com.installshield.wizard.swing.SwingWizardUI.switchToSystemLAF(SwingWizardUI.java:26)
at com.installshield.wizard.swing.SwingWizardUI.initialize(SwingWizardUI.java:216)
at com.installshield.wizard.StandardWizardListener.wizardInitializing(StandardWizardListener.java:25)
at com.installshield.wizard.Wizard$WizardListenerInitializer.run(Wizard.java:1619)
at java.lang.Thread.run(Thread.java:536)
Dynamic libraries:
0x10000 /tmp/SIEBEL/isjAAABfaqsI/bin/java
0xff350000 /usr/lib/libthread.so.1
0xff3a0000 /usr/lib/libdl.so.1
0xff200000 /usr/lib/libc.so.1
0xff340000 /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
0xfe000000 /tmp/SIEBEL/isjAAABfaqsI/lib/sparc/client/libjvm.so
0xff2e0000 /usr/lib/libCrun.so.1
0xff1e0000 /usr/lib/libsocket.so.1
0xff100000 /usr/lib/libnsl.so.1
0xff0d0000 /usr/lib/libm.so.1
0xff1c0000 /usr/lib/libmp.so.2
0xff0a0000 /tmp/SIEBEL/isjAAABfaqsI/lib/sparc/native_threads/libhpi.so
0xff070000 /tmp/SIEBEL/isjAAABfaqsI/lib/sparc/libverify.so
0xff020000 /tmp/SIEBEL/isjAAABfaqsI/lib/sparc/libjava.so
0xfe7e0000 /tmp/SIEBEL/isjAAABfaqsI/lib/sparc/libzip.so
0xfe510000 /tmp/SIEBEL/isjAAABfaqsI/lib/sparc/libnet.so
0xfe4f0000 /tmp/SIEBEL/ismp002/5868705.tmp
0xfa080000 /tmp/SIEBEL/isjAAABfaqsI/lib/sparc/libawt.so
0xfe470000 /tmp/SIEBEL/isjAAABfaqsI/lib/sparc/libmlib_image.so
0xfc490000 /tmp/SIEBEL/isjAAABfaqsI/lib/sparc/motif21/libmawt.so
0xec580000 /usr/dt/lib/libXm.so.4
0xfc420000 /usr/openwin/lib/libXt.so.4
0xfdfd0000 /usr/openwin/lib/libXext.so.0
0xfdfb0000 /usr/openwin/lib/libXtst.so.1
0xec200000 /usr/openwin/lib/libX11.so.4
0xfa3a0000 /usr/openwin/lib/libdps.so.5
0xfc7e0000 /usr/openwin/lib/libSM.so.6
0xfa150000 /usr/openwin/lib/libICE.so.6
0xec100000 /tmp/SIEBEL/isjAAABfaqsI/lib/sparc/libfontmanager.so
Local Time = Wed Feb 27 13:33:57 2008
Elapsed Time = 7
# The exception above was detected in native code outside the VM
# Java VM: Java HotSpot(TM) Client VM (1.4.1_02-b06 mixed mode)
# An error report file has been saved as hs_err_pid17568.log.
# Please refer to the file for further information.
#Hi,
any news from this error? Have you solved it?
Rgs
Janne Johansson -
Core dump loops on a forms 5 crashes
dear all,
a customer uses really old forms stuff (v 5.0.6.23.1). in some cases the forms-application crashes (not reproducible, because the app. says goodbye in different actions/triggers - i'm still investigation to find some similaries) and writes a core dump.
the curious problem is, that the generation of the dump-file loops (see the call stack below) and writes a huge f50run32_dump file (until the disk space exceeds). these ends up in a loss of service if the sysadmins don't intervene instantly.
does anyone know/hear something about such a phenomenon?
dumpfile-excerpt:
snip <<<<<<<<<<02/01/07 10:31:52 Westeuropäische Normalzeit]::Client Status [ConnId=0, PID=12980]
>> ERROR: Abnormal termination, Error Code: C0000005 ACCESS_VIOLATION
======================= STACK DUMP =======================
Fault address: 003BAEF1 01:00009EF1
Module: C:\Anwendungen\ORANT\BIN\KG734.dll
System Information:
Operating System: Windows NT Version 5.0 Build 2195 Service Pack 4
Command line: C:\Anwendungen\ORANT\BIN\F50RUN32.EXE module=unips_v.fmx
FORM/BLOCK/FIELD: AL_LAGERINFO:IDN.IDV_NR
Last Trigger: WHEN-VALIDATE-ITEM - (In Progress)
Msg: <NULL>
Last Builtin: GO_ITEM - (Successfully Completed)
Registers:
EAX:FFFFFFF8
EBX:023F9930
ECX:00000190
EDX:66FD54D8
ESI:01696A48
EDI:01D7C27C
CS:EIP:001B:003BAEF1
SS:ESP:0023:0012F02C EBP:0012F098
DS:0023 ES:0023 FS:0038 GS:0000
Flags:00010293
Call stack:
Address Frame
003BAEF1 0012F098 0001:00009EF1 C:\Anwendungen\ORANT\BIN\KG734.dll
002E1D6B 0012F110 0001:00010D6B C:\Anwendungen\ORANT\BIN\PLS234.dll
002DF7CE 0012F1A4 0001:0000E7CE C:\Anwendungen\ORANT\BIN\PLS234.dll
66F69584 023AE568 depxcnamespaceactive
016B1A8C 01DA250C 0000:00000000
023AE568 01D10C24 0000:00000000
01DA250C 016B1A8C 0000:00000000
01D10C24 023AE568 0000:00000000
016B1A8C 01DA250C 0000:00000000
023AE568 01D10C24 0000:00000000
01DA250C 016B1A8C 0000:00000000
01D10C24 023AE568 0000:00000000
016B1A8C 01DA250C 0000:00000000
023AE568 01D10C24 0000:00000000
01DA250C 016B1A8C 0000:00000000
01D10C24 023AE568 0000:00000000
016B1A8C 01DA250C 0000:00000000
023AE568 01D10C24 0000:00000000
01DA250C 016B1A8C 0000:00000000
01D10C24 023AE568 0000:00000000
snip <<<<<<<<<<i have forgotten to mention, that the the migration decision is not on my way. if i could, i had migrated the stuff to 10gR2 and assigned the problem to the oracle support.
but the last 2tier environment has already been considered. maybe that problem will force the management to react.
furthermore, i searched the metalink without any result. i hope somebody has an idea what i can check, configure, some workaround hints, etc.
does anyone know a tool for winnt to limit the max. filesize on os-level. so a loss of service can be prevented easily.
thx for your replys -
Hotspot core dumping during JVM garbage collection ?
We have an application which calls a 3rd party supplied server API which has recently been upgraded to use Java 1.5
We are getting the following error reported by our client application. The application is also now running Java 1.5 but references many classes in jar files which would have quite old code in.
The supplier of the API has stated that the problem requires us to recompile all our jar files using v 1.5 ( including things like jconnect and jms ?!?!? ). This sounds like a bit of a cop-out to me, not to mention being impossible since we don't have the source for things like jconnect.
I suspect that there is a garbage collection problem at the bottom of all this, but I'm not sure how I can "prove" this, nor do I currently have any real clue as to how to fix any GC problem that may exist.
The application is supposed to wait for a message on a MQSeries queue and then transforms it via Xalan XSLT and sends it to a Server application. I've tried playing around with heap sizes etc but that just seems to make it worse. If I leave it at the settings that the previous version used then the client at least manages to process a couple of messages before core dumping. There doesn't seem to be a consistent trigger event to cause the core dump ( it's not a message arriving on a queue for example ) but it does seem to be fairly consistent timewise, i.e. after
Any ideas gratefully accepted.
Here's a logfile excerpt from my applications showing the Hotspot error message :
=====================================================================================
08-Jul-2008 10:01:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:02:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:03:05 Waiting for messages from COLT.BBFS
405.815: [GC [PSYoungGen: 17331K->9244K(37632K)] 111702K->103615K(192128K), 0.1615910 secs]
405.977: [Full GC#
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
# An error report file with more information is saved as hs_err_pid2600.log
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
=====================================================================================
The logfile referred to in the error message contains the following.
=====================================================================================
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
--------------- T H R E A D ---------------
Current thread (0x001484d8): VMThread [id=8]
siginfo:si_signo=10, si_errno=0, si_code=1, si_addr=0x0000080f
Registers:
O0=0x00487588 O1=0xfe7d6454 O2=0x000079b0 O3=0x00007800
O4=0x00008868 O5=0x00147d48 O6=0xf8781460 O7=0xfe0f7938
G1=0xe52aaae8 G2=0x00000003 G3=0x00000003 G4=0x001484d8
G5=0xf8781d98 G6=0x00000002 G7=0xf8781d98 Y=0x805683e2
PC=0xfe141348 nPC=0xfe14134c
Top of Stack: (sp=0xf8781460)
0xf8781460: fe786000 00c6ba20 fe10013c e54bab68
0xf8781470: 0000080f e54bab6c 0000080f 00000004
0xf8781480: 00487588 00000134 e54bab6c 00000004
0xf8781490: 00000001 00000000 f87814c0 fe17aef4
0xf87814a0: fe6485b4 fe7d899c 001484d8 0011da40
0xf87814b0: 00148988 00148c10 00148d7c f8781880
0xf87814c0: 007c3389 007c3c0e 00000f87 00008868
0xf87814d0: 00008800 00487588 fe141310 fe7d6454
Instructions: (pc=0xfe141348)
0xfe141338: ec 06 c0 1a 80 a5 a0 00 22 40 00 0a ba 07 60 01
0xfe141348: f2 05 a0 00 ae 0e 60 03 80 a5 e0 03 22 40 00 05
Stack: [0xf8702000,0xf8781d98), sp=0xf8781460, free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x141348]
V [libjvm.so+0x17aefc]
V [libjvm.so+0x2d557c]
V [libjvm.so+0x300ef8]
V [libjvm.so+0x301e84]
V [libjvm.so+0x2ff950]
V [libjvm.so+0x29df30]
V [libjvm.so+0x362b44]
V [libjvm.so+0x6436f0]
VM_Operation (0xe03012b0): parallel gc system gc, mode: safepoint, requested by thread 0x0031bca0
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x00b2c028 JavaThread "Thread-4" [_thread_in_native, id=85]
0x007f5048 JavaThread "Thread-0" [_thread_blocked, id=84]
0x00c27cf0 JavaThread "Notification Delivery" [_thread_blocked, id=81]
0x0026fa08 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=73]
0x00821048 JavaThread "RMI RenewClean-[162.11.2.32:44425]" daemon [_thread_blocked, id=70]
0x0031bca0 JavaThread "GC Daemon" daemon [_thread_blocked, id=67]
0x00cd5d28 JavaThread "RMI Reaper" [_thread_blocked, id=66]
0x003c9300 JavaThread "Timer-0" daemon [_thread_blocked, id=65]
0x00929fe0 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=64]
0x0089bf18 JavaThread "SeedGenerator Thread" daemon [_thread_blocked, id=42]
0x00c47248 JavaThread "Pool thread #7" daemon [_thread_blocked, id=38]
0x00c466a0 JavaThread "Pool thread #6" daemon [_thread_blocked, id=37]
0x00311850 JavaThread "Pool thread #5" daemon [_thread_blocked, id=36]
0x00287a40 JavaThread "Pool thread #4" daemon [_thread_blocked, id=35]
0x00286e98 JavaThread "Pool thread #3" daemon [_thread_blocked, id=34]
0x00c134b0 JavaThread "Pool thread #2" daemon [_thread_blocked, id=33]
0x00ad09e0 JavaThread "Pool thread #1" daemon [_thread_blocked, id=32]
0x00286cd8 JavaThread "PoolThreadManager" daemon [_thread_blocked, id=31]
0x00c129e0 JavaThread "Channel Reaper" daemon [_thread_blocked, id=30]
0x00c669e8 JavaThread "ORB Daemon Thread" daemon [_thread_blocked, id=29]
0x00b10170 JavaThread "Worker for ServerProtocol: (iiop) /0.0.0.0:20168" daemon [_thread_blocked, id=22]
0x008a17e0 JavaThread "Syn~ Client" daemon [_thread_blocked, id=21]
0x003dc378 JavaThread "PoolScavenger0" daemon [_thread_blocked, id=20]
0x0015a928 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
0x00159880 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
0x00158a18 JavaThread "CompilerThread0" daemon [_thread_blocked, id=13]
0x00157b98 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
0x00156dc8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]
0x0014ccd8 JavaThread "Finalizer" daemon [_thread_blocked, id=10]
0x0014ad90 JavaThread "Reference Handler" daemon [_thread_blocked, id=9]
0x00038238 JavaThread "main" [_thread_in_native, id=1]
Other Threads:
=>0x001484d8 VMThread [id=8]
0x0015c3b0 WatcherThread [id=16]
VM state:at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x00037728/0x00037758] Threads_lock - owner thread: 0x001484d8
[0x00033650/0x00037ba8] Heap_lock - owner thread: 0x0031bca0
Heap
PSYoungGen total 37632K, used 9244K [0xf2eb0000, 0xf7ba0000, 0xf8400000)
eden space 28352K, 0% used [0xf2eb0000,0xf2eb0000,0xf4a60000)
from space 9280K, 99% used [0xf4a60000,0xf5367080,0xf5370000)
to space 25216K, 0% used [0xf6300000,0xf6300000,0xf7ba0000)
PSOldGen total 154496K, used 94371K [0xe8400000, 0xf1ae0000, 0xf2eb0000)
object space 154496K, 61% used [0xe8400000,0xee028e78,0xf1ae0000)
PSPermGen total 35584K, used 18260K [0xe4400000, 0xe66c0000, 0xe8400000)
object space 35584K, 51% used [0xe4400000,0xe55d5158,0xe66c0000)
Dynamic libraries:
0x00010000 /dsdvlp/java/jvm/jdk1.5.0_03/bin/java
0xff350000 /usr/lib/libthread.so.1
0xff340000 /usr/lib/libdl.so.1
0xff200000 /usr/lib/libc.so.1
0xff390000 /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
0xfe000000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server/libjvm.so
0xff1e0000 /usr/lib/libsocket.so.1
0xff2d0000 /usr/lib/libsched.so.1
0xff1b0000 /usr/lib/libCrun.so.1
0xff160000 /usr/lib/libm.so.1
0xff080000 /usr/lib/libnsl.so.1
0xff060000 /usr/lib/libmp.so.2
0xff030000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/native_threads/libhpi.so
0xfdfc0000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libverify.so
0xfdf80000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libjava.so
0xfdf50000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libzip.so
0xfb7e0000 /usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2
0xe4190000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libnet.so
0xe3bd0000 /dsdvlp/lib/5/libSolarisNatives.so
0xe3e90000 /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/librmi.so
VM Arguments:
jvm_args: -Djava.ext.dirs=/dsdvlp/java/tmijar/firs7/lib/cli:/dsdvlp/java/tmijar/firs7/lib/cli/ext:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB/ext:/dsdvlp/java/tmijar/firs7/lib/cmn:/dsdvlp/java/tmijar/firs7/lib/cmn/ext:/dsdvlp/java/tmijar/firs7/daemonlib -Duser.dir=/dsdvlp/java/tmijar/firs7 -Dopenorb.config=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB/config/SynOpenORB.xml -Dopenorb.home=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB -Dcom.coexis.syn.general.orbbinding=com.coexis.syn.general.orbbinding.openorb.OpenORBBinding_1_4 -Dsun.rmi.dgc.client.gcInterval=360000 -Dsun.rmi.dgc.server.gcInterval=360000000 -Xms32m -Xmx256m -Dcom.coexis.syn.clientcommandsconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/clientcommands.xml -Dcom.coexis.syn.clientconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/fsbbtd_client.xml -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
java_command: com.coexis.syn.mqmessaging.daemon.RunDaemon -p /dsdvlp/bin/5/lndsfsd_fsbbtd.properties start
Environment Variables:
JAVA_HOME=/dsdvlp/java/jvm/jdk150
CLASSPATH=.:/dsdvlp/java/jar/jconnect520.jar:/dsdvlp/java/jar/vbjapp340.jar:/dsdvlp/java/jar/vbjorb340.jar:/dsdvlp/java/jar/javax_jndi120.jar
PATH=/usr/local/etc:/usr/lang:/usr/openwin/bin:/usr/ucb:/bin:/usr/etc:/usr/local/5/bin:/dsdvlp/bin/5:/dsdvlp/bin/4:/home/app/sybase/5/bin:/home/app/sybase/5/localscripts:/home/app/sybase/5/sqr:/home/app/lang:/home/app/lang/SC2.0.1:/usr/ccs/bin:/usr/local/opt/Acrobat3/bin:/dsdvlp/bin:.
LD_LIBRARY_PATH=/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server:/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc:/dsdvlp/java/jvm/jdk1.5.0_03/jre/../lib/sparc:/usr/lib:/usr/openwin/lib:/usr/local/5/lib:/dsdvlp/lib/5:/dstest/lib/5:/home/app/sybase/5/lib:/dstest/cats/sun4/lib:/tmitest/Opus/opus/lib
SHELL=/bin/csh
DISPLAY=CLI00184.mfil.local:1.0
OS=5
--------------- S Y S T E M ---------------
OS: Solaris 8 2/02 s28s_u7wos_08a SPARC
Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
Assembled 18 December 2001
uname:SunOS 5.8 Generic_117350-20 sun4u (T1 libthread)
rlimit: STACK 8192k, CORE 9216k, NOFILE 4096, AS infinity
load average:2.24 2.67 2.68
CPU:total 4 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
Memory: 8k page, physical 8388608k(166384k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for solaris-sparc, built on Apr 13 2005 03:31:26 by unknown with unknown Workshop:0x550The very first suggestion I have is to move your VM to a more recent update of 1.5.0.
It looks like you are crashing with 5.0u3, and I'm pretty sure 5.0u16 is available. You
don't want to waste your time chasing a bug that's already been fixed.
Maybe you are looking for
-
Slow internet connection via AirPort on MacBook under 10.5.7
The internet connection via AirPort on my MacBook is frustratingly slow, and I have no idea why. I have an AirPort Extreme connected to a Virgin Media cable modem, a new iMac and a two year-old MacBook, both running 10.5.7. No problems at all with th
-
White Macbook 13" will not boot - Stuck in Safe Boot mode
In a nutshell -- macbook will not boot. Originally it was stuck on the gray screen with spinning wheel. Here is the course of action taken thus far (in order) 1. Reset SMC -- removed battery, pushed power button for 5-1 seconds. Rrestsarted. Not
-
Open Reader 9 files in Acrobat 5 Pro
Our office has to stick with Acrobat 5 Pro and I get files that must be open with Acrobat Reader 9 and I was wondering if there's a "fix" that would allow me to open these file in AA5 Pro. -Andy
-
Apple TV not authorized to play content?
Can anyone help with this one?
-
Spool numbers are not exist in TBTCP table but can be visible at SP01 trans
HI folks, I could see four spool errors in SP01 transaction .But i couldn't able to find which job/program had generated that spool. I have checked TBTCP table also..but those spool numbers are not exist in that table. Can any one ple