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
Thanks

Oracle 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.

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]

  • 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

  • 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

  • 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?

  • CMS crash with core files and multiple report output generation

    Happy new year to everyone,
    Our BOXIR3.1SP6FP2 env has recently started behaving weirdly by triggering multiple output to users inbox and email notification out of scheduled reports. Also we have noticed the CMS crash with core file (almost 4GB) generation at the time of multiple report output.
    Most of the times, CMC crashes and recycles itself. At few times, CMS services alone went shut down.
    OS details: RHEL 5.5, 32 GB RAM, 8 core processor on each of the clustered node, Oracle 10GR2.4 CMS DB server, 11GR2.4 oracle reporting DB server and oracle 11.1.0.6 client.
    2015/01/21 23:54:37.946|>=| | |28123|1534131088|{|||||||||||||||DBQueue::Read
    2015/01/21 23:54:37.946|==| | |28123|1496185744|
    |||||||||||||||(OracleStatement.cpp:156) Prepare: SQL: SELECT ObjectID,
    Version, LastModifyTime, CRC, Properties FROM CMS_InfoObjects6 WHERE ObjectID
    IN (1004050) ORDER BY ObjectID
    2015/01/21 23:54:37.946|==| | |28123|1496185744| ||||||||||||||(OracleStatement.cpp:183) Prepared statement Execute
    2015/01/21 23:54:37.965|==| | |28123|1496451984| |||||||||||||||SResourceSource::LoadString 50293
    2015/01/21 23:54:37.966|==| | |28123|1496451984| |||||||||||||||SResourceSource::LoadString Unknown exception in database thread
    2015/01/21 23:54:37.967|==| | |28123|1496451984| |||||||||||||||SResourceSource::LoadString 33007
    2015/01/21 23:54:37.967|==| | |28123|1496451984| |||||||||||||||SResourceSource::LoadString CMS is unstable and will shut down immediately. Reason: %1...
    2015/01/21 23:54:38.506|==| | |28123|1496185744| |||||||||||||||(OracleStatement.cpp:156) Prepare: SQL: SELECT ObjectID,
    Version, LastModifyTime, CRC, Properties FROM CMS_InfoObjects6 WHERE ObjectID IN (1009213) ORDER BY ObjectID
    2015/01/21 23:54:38.506|==| | |28123|1496185744| |||||||||||||||(OracleStatement.cpp:183) Prepared statement Execute
    2015/01/21 23:54:38.512|==| | |28123|1455592672| |||||||||||||||(sidaemon.cpp:549) SUNIXDaemon::run: server restart flag is 1..
    2015/01/21 23:54:38.513|==| | |28123|1455592672| |||||||||||||||(sidaemon.cpp:552) SUNIXDaemon::run: in abort ...
    2015/01/21 23:54:38.513|==| | |28123|1455592672| |||||||||||||||(sidaemon.cpp:555) SUNIXDaemon::run: doing the WithAbort case ...
    2015/01/21 23:54:38.520|==| | |28123|1496185744| |||||||||||||||(dbq.cpp:1357) DBQ: Time required to read 1 objects: 20.000000 ms
    Thank you,
    Karthik

    Hi Denis,
    I'm trying my best for the last few weeks to understand the core issue along with SAP however it is still a mystery.
    >Ulimit -a
    core file size          (blocks, -c) 0
    data seg size           (kbytes, -d) unlimited
    scheduling priority             (-e) 0
    file size               (blocks, -f) unlimited
    pending signals                 (-i) 270335
    max locked memory       (kbytes, -l) 32
    max memory size         (kbytes, -m) unlimited
    open files                      (-n) 1024
    pipe size            (512 bytes, -p) 8
    POSIX message queues     (bytes, -q) 819200
    real-time priority              (-r) 0
    stack size              (kbytes, -s) 10240
    cpu time               (seconds, -t) unlimited
    max user processes              (-u) 270335
    virtual memory          (kbytes, -v) unlimited
    file locks                      (-x) unlimited
    Below is the observation as part of troubleshooting:
    1. CMS breaks at threshold of 3.9 G.
    2. CMS DB sits in a different Linux server than BOE server.
    3. All core files were generated by boe_cmsd process and are almost 4GB in size (same as max threshold which it breaks).
    4. Shell script which I've added in the BOE servers shows that the CMS DB is available/connecting at the time of CMS crash.
    5. SAP analysed the Core files and skeptical about the below lines.
         #3  0x58687b80 in skgesigCrash ()
          from /opt/oracle/product/11.1.0/client_1/lib32/libclntsh.so
         #4  0x58687e0d in skgesig_sigactionHandler ()
    I'll continue troubleshooting with a hope to fix it at the earliest.
    Thanks,
    Karthik

  • Python crashes.  Core dump inside xcurses2/tgetent(): cur_term is nil

    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

  • Application dying with core dump on what appears to be berkeley

    I have a web app being run on a solaris server. This web app ran for approximately 20 hours before crashing. I have the core dump file, but it is quite large (11GB). Using mdb I am able to get the stack trace from the core dump. Could this be an issue with a corrupted BDB? Or could it be corrupted environment file(s)? A similar, but different (slightly different stack trace) error that happened on another server a few hours later. We have 3 other servers that continue to run successfully though with the same BDB objects.
    We are not writing to any of the BDBs. They are read only. Same with secondary BDBs. It is a java webapp interacting with the native solaris libraries. I forgot to add, this is a 64 bit machine.
    If you have any ideas/suggestions/need more info please let me know.
    Top of the stack trace below.
    libc.so.1`_lwp_kill+8(6, 0, ffffffff7ef45538, ffffffffffffffff, ffffffff7ef3a000, 0)
    libc.so.1`abort+0x118(1, 1d8, ffffffff7e2fc6f8, 1ef13c, 0, 0)
    libjvm.so`__1cCosFabort6Fb_v_+0x58(1, 1, 2dbc8, ffffffff7e69e000, 3abb94, 2d800)
    libjvm.so`__1cHVMErrorOreport_and_die6M_v_+0xcb4(ffffffff7e700480, 0, 1, ffffffff7e70ace0, ffffffff7e6cbb80, ffffffff7e55c873)
    libjvm.so`JVM_handle_solaris_signal+0xa6c(a, fffffffccbefd500, fffffffccbefd220, 1a0c00, 101b8a800, 280000)
    libc.so.1`__sighndlr+0xc(a, fffffffccbefd500, fffffffccbefd220, ffffffff7ddf5df0, 0, 9)
    libc.so.1`call_user_handler+0x3e0(ffffffff7bc15a00, ffffffff7bc15a00, fffffffccbefd220, c, 0, 0)
    libc.so.1`sigacthandler+0x54(0, fffffffccbefd500, fffffffccbefd220, ffffffff7bc15a00, 0, ffffffff7ef3a000)
    libdb_java-4.6.so`__env_alloc_free+0x140(100bab1c0, fffffffc6c0c75f8, fffffffc8bcff5dc, 1a, 66e, fffffffccbefe461)
    libdb_java-4.6.so`__memp_free+0x1c(100bab1c0, fffffffc82123140, fffffffc6c0c75f8, fffffffccbefe710, 0, fffffffc6a00f1d0)
    libdb_java-4.6.so`__memp_bhfree+0x6fc(100fc46e0, 100bab1c0, fffffffc6a00f1c8, fffffffc6c0c75f8, 1, 3)
    libdb_java-4.6.so`__memp_alloc+0x1df8(100fc46e0, 100bab1c0, fffffffc82100698, 0, 0, fffffffccbefdeb0)
    libdb_java-4.6.so`__memp_fget+0x233c(100ba5e50, 10142eb84, 0, 1, 10142eb78, 0)
    libdb_java-4.6.so`__ham_get_cpage+0x33c(101258860, 1, 4, 1, 10142ebc8, 10142ebb0)
    libdb_java-4.6.so`__ham_lookup+0x104(101258860, fffffffccbefe770, 0, 1, fffffffccbefe34c, 4c000)
    libdb_java-4.6.so`__hamc_get+0x278(101258860, fffffffccbefe770, fffffffccbefe710, 1a, fffffffccbefe34c, 0)
    libdb_java-4.6.so`__dbc_get+0x81c(101258860, fffffffccbefe770, fffffffccbefe710, 1a, 66e, fffffffccbefe461)
    libdb_java-4.6.so`__db_get+0x1a4(1012b2570, 0, fffffffccbefe770, fffffffccbefe710, 0, 4c000)
    libdb_java-4.6.so`__db_get_pp+0x3e0(1012b2570, 0, fffffffccbefe770, fffffffccbefe710, 0, fffffffccbefe700)
    libdb_java-4.6.so`Db_get+0x40(1012b2570, 0, fffffffccbefe770, fffffffccbefe710, 0, 0)
    libdb_java-4.6.so`Java_com_sleepycat_db_internal_db_1javaJNI_Db_1get+0x128(101b8a9b8, fffffffccbefe8e8, 1012b2570, 0, fffffffccbefe8c8, fffffffccbefe8d0)
    0xffffffff78391410(1012b2570, 0, ffffffff11fc9a38, ffffffff11fc9a70, 0, fffffffccbefe101)
    0xffffffff78005eac(ffffffff559ee358, b6, fffffffce2f93180, ffffffff78018100, 7124, fffffffccbefe221)
    0xffffffff78005eac(ffffffff559ee338, b6, fffffffce2f92f60, ffffffff78017d20, ae1, fffffffccbefe331)
    0xffffffff78005e60(ffffffff5fad4f80, b7, fffffffce2ff6ac0, ffffffff78017d28, 66e, fffffffccbefe461)
    0xffffffff78005e60(ffffffff5fad4f80, fffffffce150e618, fffffffce2f9dd20, ffffffff78017f60, 5, fffffffccbefe5e1)
    0xffffffff780063b8(ffffffff5fad4f20, b7, 0, ffffffff78018200, 1e400, fffffffccbefe701)
    0xffffffff78005e60(ffffffff5fad4f20, fffffffce14a5828, 0, ffffffff78017f60, ffffffff11ff0cf0, fffffffccbefe811)
    0xffffffff780063b8(ffffffff5f995ce0, fffffffce145f868, 0, ffffffff78017ce0, ffffffff11ff0cf0, fffffffccbefe931)
    0xffffffff780063b8(ffffffff5f995d78, b6, 0, ffffffff78018200, ffffffff11ff0cf0, fffffffccbefea51)
    0xffffffff78005fdc(fffffffef354e068, fffffffce00427e0, 0, ffffffff78017ce0, 0, fffffffccbefeb71)
    0xffffffff78006534(fffffffef354e0f8, b7, 0, ffffffff78018200, 0, fffffffccbefecb1)
    0xffffffff78005fdc(fffffffef354e0f8, fffffffce00427e0, 0, ffffffff78017f60, 912c14, fffffffccbefedc1)
    0xffffffff78006534(fffffffccbefff50, 60800, 0, ffffffff78018200, fffffffef354e178, fffffffccbefeeb1)
    0xffffffff78000240(fffffffccbeff8a0, fffffffccbeffd50, a, fffffffce00441e8, ffffffff7800bda0, fffffffccbeffb48)
    libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x1f4(1, 101b8a800, fffffffccbeffb38, a,
    ffffffff780001e0, fffffffccbeff870)
    libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThread__v_+0x130(fffffffccbeffd48,
    ffffffff7e6ea148, fffffffef354e178, 4c148, fffffffccbeffb38, ffffffffff6f4950)
    libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x50(fffffffccbeffd48, 100c8f880, 100c8f888,
    ffffffff7e71c2b0, ffffffff7e71c798, 101b8a800)
    libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0xf0(fffffffef354e178, 101b8a800, 7dd50, 85fc64, ffffffff7e71bd50, 7dc00)
    Edited by: user11287228 on Jun 9, 2011 11:33 AM

    Hello,
    If you can one thing that might help is rebuilding the Berkeley DB library with enable-debug and enable-diagnostic. With enable-debug we might get line numbers and see exact where we are in __env_alloc_free and see what the input parameters leading up to the abort are. With enable-diagnostic run-time checking is in place which might also help see what is causing this. (see http://download.oracle.com/docs/cd/E17076_02/html/installation/build_unix_conf.html) Another thing to do if you are not using a private environment is to look at the db_stat -E output:
    http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/db_stat.html
    Thank you,
    Sandra

  • Delegate Admin install fails with core dump

    I have been attempting to install the iPlanet Delegated Adminstrator with the Messaging Server 5.2 release. I am using Directory Server 5.1 service pack 1 on Solaris 8.
    Installation of DS 5.1 goes fine.
    Installation of MS 5.2 goes fine.
    Installation of the web server 6.0 wtih sp4 goes fine
    Every time I attempt to install DA, I get a "Segmentation Fault - core dumped" and absolutely no other information.

    Since this is not a normal thing, I only have two suggestions left:
    1. Download the latest version if iDA:
    http://wwws.sun.com/software/download/products/3ed69a6c.html
    2. Download and apply p1 for iMS (now a year old, but the latest publically available version):
    http://wwws.sun.com/software/download/products/3e3afb91.html
    3. Install the latest Solaris patch cluster.
    If the above fail, then:
    4. Open up a tech support ticket.

  • JRockit Crashes with empty dump file.

    ---Symptom:
    JRockit creates an empty dump file and dies without fully starting
    Dump file looks like this:
         [user@computer some_dir]$ cat jrockit.25058.dump
         ===== BEGIN DUMP ===============================
         [user@computer some_dir]$
    ---Cause:
    ulimit -s 2048
    This limits the stack size which apparently causes problems for JRockit.
    This limit had been set to workaround a known issue in the Sun JVM.
    ---Workaround:
    Use system default stack size or a size larger than 2048.
    ---Environment:
    Java:
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
    BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1032-linux-ia32, Native Threads, GC strategy: parallel)
    OS:
    Linux DL580 2.4.21-15.ELsmp #1 SMP Thu Apr 22 00:18:24 EDT 2004 i686 i686 i386 GNU/Linux

    Bandas,
    The crash most likely happens because you have very little memory left on your system.
    In the dump you can find the following message:
    "C Heap : 3 memory allocations have failed"
    This indicates that three malloc have failed internally. Given additional information in the dump it looks like an allocation did fail during garbage collection internally within the JVM that caused this crash. We have been working at improving the error message on these kinds of complete out of memory situations.
    The best thing you can do is to reduce the java-heap size which will make more native memory available.
    Another thing you can try if you haven't is to boot up windows in /3GB mode which will give JRockit access to the an additional 1GB of memory. (Your machine seem to have 3GB+ memory so booting Windows with the /3GB switch will allow JRockit to take advantage of that memory)
    I hope this helps

  • Help with core dump.

    We have a Tomcat app that is hanging every 3-4 days. I know this is off-topic, but I'd appreciate any help in resolving this. I've posted the JVM dump on my web page at http://web.bvu.edu/staff/david/jvmdmp.txt
    Additional details:
    JDK 1.4.2_08 on Windows Server 2003 Enterprise, Tomcat 5.0.28
    The web app runs agains MySQL 4.0.26 which is on a separate server, also Windows Server 2003 Enterprise. We're using the MySQL 3.1.10 connector.
    The hangs happen on each version of Tomcat (4.1.31, 5.0.28, 5.5.9), MySQL (4.0.26, 4.1.15), and Java (1.4.2, 1.5) we've tried. No errors being reported on the MySQL side of things, and no unusual Exceptions in the Tomcat/JVM logs.

    [http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/crashes.html]

  • Weblogic crashes with a coredump on solaris

    Hi All,
    Recently our weblogic server on solaris started to give core dumps.
    It doesnt say why it crashed and the only available information are the
    coredump file and the log file which is created for that crash. One other
    noticable thing was somewhere in the output it said,
    An irrecoverable stack overflow has occurred.
    Unexpected Signal : 11 occurred at PC=0xb77e8
    Function name=(N/A)
    Library=(N/A)
    NOTE: We are unable to locate the function name symbol for the error
    just occurred. Please refer to release documentation for possible
    reason and solutions.
    Current Java thread:
    Dynamic libraries:
    0x10000 /opt/customer/bea/jdk131/jre/bin/sparc/native_threads/java
    0xff350000 /usr/lib/libthread.so.1
    0xff390000 /usr/lib/libdl.so.1
    0xff200000 /usr/lib/libc.so.1
    0xff330000 /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
    0xfe000000 /opt/customer/bea/jdk131/jre/lib/sparc/server/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
    0xff310000 /usr/lib/libw.so.1
    0xff0b0000 /usr/lib/libmp.so.2
    0xff080000 /opt/customer/bea/jdk131/jre/lib/sparc/native_threads/libhpi.so
    0xff050000 /opt/customer/bea/jdk131/jre/lib/sparc/libverify.so
    0xfdc80000 /opt/customer/bea/jdk131/jre/lib/sparc/libjvm.so
    0xfe7c0000 /opt/customer/bea/jdk131/jre/lib/sparc/libjava.so
    0xff020000 /opt/customer/bea/jdk131/jre/lib/sparc/libzip.so
    0xfe560000 /usr/lib/locale/en_US.ISO8859-15/en_US.ISO8859-15.so.2
    0xfe530000 /opt/customer/bea/jdk131/jre/lib/sparc/libhprof.so
    0xfc920000 /opt/customer/bea/jdk131/jre/lib/sparc/libnet.so
    0xfa6e0000 /usr/lib/nss_files.so.1
    0xfa6c0000 /opt/customer/bea/wlserver6.1/lib/solaris/libmuxer.so
    0xfa6a0000 /usr/ucblib/libucb.so.1
    0xfa460000 /usr/lib/libresolv.so.1
    0xfa420000 /usr/lib/libelf.so.1
    Local Time = Wed May 29 15:21:52 2002
    Elapsed Time = 13736
    # HotSpot Virtual Machine Error : 11
    # Error ID : 4F530E43505002C4 01
    # Please report this error at
    # http://java.sun.com/cgi-bin/bugreport.cgi
    # Java VM: Java HotSpot(TM) Server VM (1.3.1_01 mixed mode)
    # An error report file has been saved as hs_err_pid26165.log.
    # Please refer to the file for further information.
    Abort - core dumped
    LD_LIBRARY_PATH=/opt/customer/bea/wlserver6.1/lib/solaris:/opt/customer/bea/
    wlserver6.1/lib/solaris/oci816_8:/usr/local/lib
    Any ideas? I can send the coredump if required.
    Thank You
    Saman

    So your SP2 machines are more stabel than SP3 and SP4?
    Thanks,
    Chuck
    Kevin Toomey wrote:
    I'm seeing something similiar. I recently upgraded our admin server to SP4 and
    JDK 1.3.1_06. Some of the managed servers in the domain are still at SP2 with
    JDK 1.3.1_02. The admin server is crashing with no dumps and no error messages
    to the log.
    Hella <[email protected]> wrote:
    We have been experiencing numerous crashes (with core dumps) runninig
    6.1sp3 on Solaris 8 64-bit. The server is at the latest recommended
    patch cluster (to include the J2SE patch cluster) We are using J2SE
    1.3.1 and have tried all revisions to include 06. It seems the 04 rev
    is
    the most stable but still we get numerous crashes a day.
    Does anyone know of any problems with the above combinations?
    Thanks greatly,
    Chuck

  • F60desm generates core dump

    I have the following problem. I Have loaded Oracle Developer Version 6.0 for Compaq Tru64 Unix v4.0F onto a Alphastation 255. I loaded the following Oracle products.
    Net 8.0.5.0.0
    Oracle Forms Client Server
    Oracle Graphics Client Server
    Oracle Reports Client Server
    Oracle Unix Installer 4.0.3
    PL/SQL Procedure Builder
    SQL*PLUS 8.0.5.0.0
    TCP/IP Protocol Adapter 8.0
    While running f60desm, I can sucessfully connect to a NT box and in the Data Block Wizard, I can select a table and select columns. When I select BACK, NEXT, or FINISH, I get a segmentation fault with core dump.
    Thanking you in advance for your help.
    regards,
    Shailen.
    null

    Hi
    I am facing the problem of core dump while running f60desm on HP-UX 11.00.
    In my case core dump immediately appears after run the f60desm.
    All other product exe like f45genm, g60desm are working fine except f60desm.
    Could you pl. show some light on this ?
    Can you give some workaround for the problem ?
    Awaiting reply.
    Regds
    Bala

  • Java crashes on a solaris 9 randomly with a core dump

    Hello
    Currently we are using JBoss Application server on solaris 9. Over a period of time. Java crashes suddenly. The condition under which this can be reproduced is currently not reproduceable. But over a period of time, this crash just happens.
    The following is the stack trace of the core file. Can somebody see this and let me know what could be the possible problem.
    bash-2.05# adb java.3558.1133780573
    core file = java.3558.1133780573 -- program `` /global/netmfs/netmbase/NetM62/licensing/jre/bin/java'' on platform SUNW,Sun-Fire-V440
    SIGABRT: Abort
    $c
    libc.so.1`_lwp_kill+8(6, 0, acf7b6e8, 2, 0, af2d482c) libc.so.1`abort+0x100(2d80f8, b, b3ef0040, 0, 48, 0) libkernel32.so`__1cUSehScanInvokeTryList6FpnQSEH_THREAD_BLOCK__i_+0x334(2d9790,
    af1cd7f8, af2d7324, 0, 2, 0)
    libkernel32.so`__1cOSignal_HandlerFraise6FIpviipL_i_+0xfc(c0000005, acf7ba20, 0 , 2, acf7b858, 1800) libkernel32.so`__1cPRaise_Exception2f6MipnHsiginfo_pv_v_+0xa4(516f28, b, acf7bcd8, acf7ba20, af2ea1e4, 2c) libthread.so.1`__sighndlr+0xc(b, acf7bcd8, acf7ba20, af1cd854, 0, 0) libthread.so.1`call_user_handler+0x234(b, acf7bcd8, acf7ba20, 0, 0, 0) libthread.so.1`sigacthandler+0x64(b, acf7bcd8, acf7ba20, 1, f6e89af0, 3ba) 0xfa0f4520(b5fec400, f6e89af0, b5fec550, 3ba, fa015624, b5fed448) 0xfa43586c(f5c770a8, b5fec530, bcdddf90, b5fec530, bcdddf90, b5fec400) 0xfa005b10(f6e8a270, b6, 8, fa0155e0, f6e847a0, acf7bf70) 0xfa005b10(2d6b00, b8, acf7c0e4, fa0152c0, fa015624, acf7c000) 0xfa005b10(2d6b00, b8, 8, fa015590, feca1858, acf7c078) 0xfa005b10(2d6b00, 0, 0, fa0155e0, 3349f0, acf7c108) 0xfa000118(acf7c1f0, acf7c388, a, f6e89818, fa00aae0, acf7c328) libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallAr
    guments_pnGThread__v_+0x274(acf7c380, acf7c318, acf7c320, 2d6b00, 2d6b00, 34e9cc
    libjvm.so`JVM_DoPrivileged+0x4c0(632adc, ff0104d0, acf7c65c, 0, 1, 1) libjava.so`Java_java_security_AccessController_doPrivileged__Ljava_security_Priv
    ilegedExceptionAction_2+0x14(2d6b94, acf7c5e0, acf7c65c, ffffffff, fa015624, 0) 0xfa00be48(2d6b00, b8, 15c, 4, f6e847a0, acf7c5f8) 0xfa005b10(2d6b00, 0, 0, fa015480, 3349f0, acf7c690) 0xfa000118(acf7c778, acf7c838, a, f6e87d18, fa00aae0, acf7c844) libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallAr
    guments_pnGThread__v_+0x274(acf7c830, acf7c82c, acf7c840, 2d6b00, 2d6b00,
    acf7d170)
    libjvm.so`__1cNinstanceKlassbBcall_class_initializer_impl6FnTinstanceKlassHandle
    pnGThread_v_+0xfc(acf7c950, 2d6b00, 10b, acf7c9e8, 1, 0) libjvm.so`__1cNinstanceKlassPinitialize_impl6FnTinstanceKlassHandle_pnGThread__v
    +0x4f4(acf7ca98, 2d6b00, acf7d490, 2d741c, 2d6b00, 0) libjvm.so`_1cNinstanceKlassKinitialize6MpnGThread__v_+0x84(f6e87dd0, 2d6b00, 1b8, f5c01e00, acf7cb5c, 1) libjvm.so`__1cMLinkResolverTresolve_static_call6FrnICallInfo_rnLKlassHandle_nMsy
    mbolHandle_53iipnGThread__v_+0x190(0, 2d6b00, ff0104d0, acf7cc54, acf7cc50, 1) libjvm.so`__1cMLinkResolverOresolve_invoke6FrnICallInfo_nGHandle_nSconstantPoolH
    andle_inJBytecodesECode_pnGThread__v_+0xd8(acf7cf44, acf7cf0c, acf7cf08, 12, b8 , 2d6b00) libjvm.so`__1cSInterpreterRuntimeOresolve_invoke6FpnKJavaThread_nJBytecodesECode
    __v_+0x6ac(2d6b00, b8, 8, b5feaea8, f6e80c78, 0) 0xfa01561c(2d6b00, b8, b5feaf20, fa015590, fa015624, acf7d0d0) 0xfa005b10(2d6b00, b8, 1b9, fa015590, f6dc6a20, acf7d170) 0xfa005b10(2d6b00, b8, 8, fa0155e0, f6dc6a20, acf7d208) 0xfa005b10(2d6b00, b8, acf7d3ac, fa015590, f6dc9888, acf7d2b0) 0xfa005b10(2d6b00, b8, 8, fa015590, f6dc6a20, acf7d340) 0xfa005b10(2d6b00, 0, 0, fa0155e0, 3349f0, acf7d3c8) 0xfa000118(acf7d4b0, acf7d570, a, f6dc87d0, fa00aae0, acf7d57c) libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallAr
    guments_pnGThread__v_+0x274(acf7d568, acf7d564, acf7d578, 2d6b00, 2d6b00, 0) libjvm.so`__1cNinstanceKlassbBcall_class_initializer_impl6FnTinstanceKlassHandle
    pnGThread_v_+0xfc(acf7d688, 2d6b00, 10b, acf7d720, 1, 0) libjvm.so`__1cNinstanceKlassPinitialize_impl6FnTinstanceKlassHandle_pnGThread__v
    +0x4f4(acf7d7d0, 2d6b00, acf7e118, 2d72c4, 2d6b00, b5c49570) libjvm.so`_1cNinstanceKlassKinitialize6MpnGThread__v_+0x84(f6dc9700, 2d6b00, 1b8, f5c01e00, acf7d894, 1) libjvm.so`__1cMLinkResolverTresolve_static_call6FrnICallInfo_rnLKlassHandle_nMsy
    mbolHandle_53iipnGThread__v_+0x190(0, 2d6b00, ff0104d0, acf7d98c, acf7d988, 1) libjvm.so`__1cMLinkResolverOresolve_invoke6FrnICallInfo_nGHandle_nSconstantPoolH
    andle_inJBytecodesECode_pnGThread__v_+0xd8(acf7dc7c, acf7dc44, acf7dc40, 6d, b8 , 2d6b00) libjvm.so`__1cSInterpreterRuntimeOresolve_invoke6FpnKJavaThread_nJBytecodesECode
    __v_+0x6ac(2d6b00, b8, acf7de5c, fa0155d8, fa015624, acf7dd50) 0xfa01561c(2d6b00, b8, b5c47f38, fa015590, f67cf4d0, acf7dde8) 0xfa005a44(2d6b00, b8, 3, fa015590, fa015304, acf7deb8) 0xfa005b54(be833b70, b6, acf7e024, fa015590, fa015304, acf7df48) 0xfa005b54(be833b78, b6, acf7e0a4, fa015270, b6080000, acf7dfc8) 0xfa005b54(2d6b00, 0, 0, fa015270, 3349f0, acf7e048) 0xfa000118(acf7e138, acf7e270, a, f67d9ba0, fa00aae0, acf7e2ac) libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallAr
    guments_pnGThread__v_+0x274(acf7e268, acf7e264, acf7e29c, 2d6b00, 2d6b00,
    fece7f70)
    libjvm.so`__1cKReflectionGinvoke6FnTinstanceKlassHandle_nMmethodHandle_nGHandle_
    inOobjArrayHandle_nJBasicType_4ipnGThread__pnHoopDesc__+0xeec(0, acf7e3c0, ff0104d0, 1, f67cf810, a) libjvm.so`__1cKReflectionNinvoke_method6FpnHoopDesc_nGHandle_nOobjArrayHandle_pn
    GThread__2_+0x230(be3e4900, acf7e448, acf7e444, 2d6b00, feda0bd0, acf7e810) libjvm.so`JVM_InvokeMethod+0x26c(acf7e5b0, acf7e5ac, ff005ddc, ff0073e8, c6, 0) libjava.so`Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x10(2d6b94,
    acf7e528, acf7e5b4, acf7e5b0, acf7e5ac, 0) 0xfa00be48(b5fed8d0, b8, acf7e634, c, b6080000, acf7e540) 0xfa005b10(b5fefd98, be8339c0, b5fed8d0, fa015590, f6b5c960, acf7e5d8) 0xfa2267c4(b5fefdb0, be8339c0, b60a0028, fa015270, 1, acf7e648) 0xfa2264e0(be3f5ca8, be8339c0, b60a0028, be3f5c70, f5c2a550, f5c2a550) 0xfa005b10(be41d6d8, f65ee028, acf7e878, fa015270, f68e6d70, acf7e778) 0xfa005fd8(be40db50, f65ee028, acf7e914, fa0156f0, f6229940, acf7e810) 0xfa005fd8(be3f6f48, b6, 49, fa0156f0, c6, acf7e8b0) 0xfa005b10(be3f6f48, b7, acf7ea70, fa0152b8, 0, acf7e978) 0xfa005b10(be3f6f48, f65ee028, acf7eb00, fa015430, fa00aae0, acf7ea10) 0xfa005fd8(be3ebba8, f65ee028, acf7eb98, fa0156f0, 2d6b00, acf7eaa0) 0xfa005fd8(be481ee8, f65ee028, acf7ec30, fa0156f0, 42e6f04c, acf7eb38) 0xfa005fd8(be47c270, f65ee028, acf7ecc0, fa0156f0, 1, acf7ebd0) 0xfa005fd8(be448ef8, b6, acf7ed90, fa0156f0, f620a188, acf7ec50) 0xfa005b10(be448ef8, b6, 0, fa015270, b6080000, acf7ed18) 0xfa005b10(be449a38, b6, acf7eed0, fa015270, c6, acf7edc8) 0xfa005b10(be6e0488, f5ee2070, 4, fa015270, f5c045c0, acf7ee58) 0xfa005fd8(2d6b00, 0, 0, fa015740, 3349f0, acf7ef00) 0xfa000118(acf7eff0, acf7f128, a, f67f5f50, fa00aae0, acf7f164) libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallAr
    guments_pnGThread__v_+0x274(acf7f120, acf7f11c, acf7f154, 2d6b00, 2d6b00,
    fece7f70)
    libjvm.so`__1cKReflectionGinvoke6FnTinstanceKlassHandle_nMmethodHandle_nGHandle_
    inOobjArrayHandle_nJBasicType_4ipnGThread__pnHoopDesc__+0xeec(0, acf7f278, ff0104d0, 1, f67cf810, a) libjvm.so`__1cKReflectionNinvoke_method6FpnHoopDesc_nGHandle_nOobjArrayHandle_pn
    GThread__2_+0x230(be849d88, acf7f300, acf7f2fc, 2d6b00, feda0bd0, acf7f6c8) libjvm.so`JVM_InvokeMethod+0x26c(acf7f468, acf7f464, ff005ddc, ff0073e8, 20, 0) libjava.so`Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x10(2d6b94,
    acf7f3e0, acf7f46c, acf7f468, acf7f464, 0) 0xfa00be48(b5fed810, b8, acf7f4ec, c, b6080000, acf7f3f8) 0xfa005b10(b5fed8a8, be6d7ab8, b5fed810, fa015590, 3230bc, acf7f490) 0xfa2267c4(b5fed8c0, be6d7ab8, b60a0000, fa015270, be843a68, acf7f500) 0xfa2264e0(b5fed858, be6d7ab8, b60a0000, b5fed858, 1, 0) 0xfa005b10(be6de080, b6, b5fed858, fa015270, be6d4478, acf7f620) 0xfa005b10(be6de080, b6, acf7f7c8, fa015270, 96, acf7f6c8) 0xfa005b10(be6de080, f5ee2070, 4, fa015270, f5c045c0, acf7f750) 0xfa005fd8(be6d6a18, f67d91d0, 8, fa015740, fa015304, acf7f7f8) 0xfa00601c(be6a3ac0, b6, 8, fa015590, 8, acf7f8a0) 0xfa005b54(be6a3ac0, f640af90, acf7fa7c, fa015270, f640af90, acf7f978) 0xfa005fd8(be8338f8, b7, 0, fa0156f0, f640af90, acf7fa08) 0xfa005c64(be8338f8, b7, acf7fb18, fa015430, be8338f8, acf7fab0) 0xfa005c64(acf7fba8, 0, 0, fa015430, 3349f0, acf7fb48) 0xfa000118(acf7fc30, acf7fe98, a, f6496780, fa00aae0, acf7fdb8) libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallAr
    guments_pnGThread__v_+0x274(acf7fe90, acf7fcf8, acf7fdb0, 2d6b00, 2d6b00,
    acf7fd08)
    libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle
    _4pnRJavaCallArguments_pnGThread__v_+0x164(feff0000, 2d71e8, acf7fda4, acf7fda0 , acf7fdb0, 2d6b00) libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsym
    bolHandle_5pnGThread__v_+0x60(acf7fe90, acf7fe8c, acf7fe84, acf7fe7c, acf7fe74,
    2d6b00)
    libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x128(2d6b00, 2d6b00, 2d6190, 2d71e8, 319508, fecd6a5c) libjvm.so`__1cKJavaThreadDrun6M_v_+0x288(2d6b00, 0, ff00f808, ffff8000, 0, 0) libjvm.so`_start+0x134(2d6b00, 0, 0, 0, 0, 0) libthread.so.1`_lwp_start(0, 0, 0, 0, 0, 0)
    Second Core dump with adb
    bash-2.05# adb java.9337.1133744404
    .core file = java.9337.1133744404 -- program `` /global/netmfs/netmbase/NetM62/licensing/jre/bin/java'' on platform SUNW,Sun-Fire-V440
    SIGABRT: Abort
    .$c
    $c
    libc.so.1`_lwp_kill+8(6, 0, ad0fc950, 2, 0, aeed482c) libc.so.1`abort+0x100(bd90f8, b, b3670200, 0, 48, 0) libkernel32.so`__1cUSehScanInvokeTryList6FpnQSEH_THREAD_BLOCK__i_+0x334(6197b0,
    aedcd7f8, aeed7324, 0, 2, 0)
    libkernel32.so`__1cOSignal_HandlerFraise6FIpviipL_i_+0xfc(c0000005, ad0fcc88, 0 , 2, ad0fcac0, 1800) libkernel32.so`__1cPRaise_Exception2f6MipnHsiginfo_pv_v_+0xa4(50c028, b, ad0fcf40, ad0fcc88, aeeea1e4, 2c) libthread.so.1`__sighndlr+0xc(b, ad0fcf40, ad0fcc88, aedcd854, 0, 0) libthread.so.1`call_user_handler+0x234(b, ad0fcf40, ad0fcc88, 0, 0, 0) libthread.so.1`sigacthandler+0x64(b, ad0fcf40, ad0fcc88, fa015590, b6130000,
    ad0fcfc0)
    0xfa0157f0(b5cb5908, b6, 8, fa015740, 0, ad0fd070) 0xfa005c64(b5cb5908, b7, ad0fd208, fa015270, b5cb1c90, ad0fd118) 0xfa005c64(b5cb5908, b7, 0, fa015430, b6130000, ad0fd1a8) 0xfa005c64(be56d460, b6, 8, fa015430, f691f2b0, ad0fd240) 0xfa005b10(be56d498, b6, be574c70, fa015270, 4889ba9b, ad0fd330) 0xfa005b10(be56d4a8, b7, ad0fd4d4, fa015270, 9, ad0fd3c8) 0xfa005b10(be56d4a8, b7, 0, fa015430, b6130000, ad0fd448) 0xfa005b10(be56d4a8, f6915008, 8, fa015430, 42a1665e, ad0fd540) 0xfa005fd8(bd44ecd0, f63b2338, ad0fd6c4, fa0156f0, b5cb4b38, ad0fd5d8) 0xfa005fd8(b5cb4a60, b7, ad0fd6d0, fa0156f0, b5cb4b48, ad0fd660) 0xfa005b10(b5cb4a60, b6, ad0fd818, fa015430, f65b7528, ad0fd718) 0xfa005b10(bd41bcf0, f63b1548, ad0fd8a0, fa015270, b6130000, ad0fd7b8) 0xfa005fd8(bd410620, b7, ad0fd934, fa0156f0, b6130000, ad0fd840) 0xfa005b10(bd410620, b6, ad0fd9c4, fa015430, b6130000, ad0fd8d0) 0xfa005b10(bd410620, b6, ad0fda44, fa015270, b6130000, ad0fd968) 0xfa005b10(bd8d1420, f63aa0c8, ad0fdad4, fa015270, 4400, ad0fd9e8) 0xfa005fd8(bd8c7f60, f65c2490, ad0fdb5c, fa0156f0, f6906720, ad0fda70) 0xfa005fd8(be548400, f68f50b0, ad0fdbe8, fa0156f0, f65b4158, ad0fdaf0) 0xfa005fd8(b5caf718, f6d147c0, 0, fa0156f0, b6130000, ad0fdb80) 0xfa005fd8(b5caeb10, b7, ad0fdcf8, fa0156f0, b6130000, ad0fdc10) 0xfa005c64(b5caeb10, f6a62080, ad0fdd8c, fa015430, f6ad6088, ad0fdc90) 0xfa005fd8(b5caf718, f6d147c0, ad0fde3c, fa0156f0, b6130000, ad0fdd20) 0xfa005fd8(be6abc20, b6, 0, fa015738, b6130000, ad0fddd0) 0xfa005b10(be6abc20, b7, ad0fdf94, fa015270, 4400, ad0fdea0) 0xfa005b10(be6abc20, b7, 0, fa015478, b6130000, ad0fdf38) 0xfa005b10(be6abc20, b7, 0, fa015478, f6864318, ad0fdfc8) 0xfa005b10(be6abc20, b6, ad0fe14c, fa015430, 3230bc, ad0fe058) 0xfa005b10(be6abc20, b7, ad0fe1d8, fa015270, b6130000, ad0fe0f0) 0xfa005b10(be6abc20, f6ad6088, ad0fe264, fa015430, f6ad6088, ad0fe178) 0xfa005fd8(be695da8, f6ab5750, 0, fa0156f0, b6130000, ad0fe208) 0xfa005fd8(b5caeb10, b7, ad0fe3ac, fa0156f0, f65b4158, ad0fe2a8) 0xfa005b10(b5caeb10, b7, ad0fe43c, fa015478, b6130000, ad0fe350) 0xfa005b10(b5caeb10, f6a62080, ad0fe4c8, fa015478, f5c355f8, ad0fe3e0) 0xfa005fd8(be7db4e8, b6, ad0fe55c, fa0156f0, aeed28, ad0fe468) 0xfa005b10(be7db4e8, b7, 0, fa015590, b6130000, ad0fe4f0) 0xfa005b10(be7db4e8, f6da8e80, ad0fe664, fa0156f0, fa0154c4, ad0fe580) 0xfa005fd8(be7d8e20, b7, ad0fe700, fa015270, f68e2490, ad0fe608) 0xfa005c64(be7d8e20, b7, ad0fe788, fa015430, fa0154c4, ad0fe6a0) 0xfa005c64(be7d8e20, b7, ad0fe808, fa015270, fa015624, ad0fe728) 0xfa005c64(aeed28, b8, ad0fe888, fa015430, f5c05cb0, ad0fe7a8) 0xfa005c64(b5c556a8, f66f5b10, ad0fe910, fa015270, f66f5b10, ad0fe828) 0xfa00612c(aeed28, 0, 0, fa0156f0, 3349f0, ad0fe8b0) 0xfa000118(ad0fe9a0, ad0fead8, a, f66f5668, fa00aae0, ad0feb10) libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallAr
    guments_pnGThread__v_+0x274(ad0fead0, ad0feacc, ad0feb04, aeed28, aeed28,
    fece7f70)
    libjvm.so`__1cKReflectionGinvoke6FnTinstanceKlassHandle_nMmethodHandle_nGHandle_
    inOobjArrayHandle_nJBasicType_4ipnGThread__pnHoopDesc__+0xeec(0, ad0fec28, ff0104d0, 1, f655dbd0, e) libjvm.so`__1cKReflectionNinvoke_method6FpnHoopDesc_nGHandle_nOobjArrayHandle_pn
    GThread__2_+0x230(be023bb0, ad0fecb0, ad0fecac, aeed28, feda0bd0, ad0ff080) libjvm.so`JVM_InvokeMethod+0x26c(ad0fede8, ad0fede4, ff005ddc, ff0073e8, f6159f00, ad0ff120) libjava.so`Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x10(aeedbc,
    ad0fed84, ad0fedec, ad0fede8, ad0fede4, fece6088) 0xfa4067a8(be07f5a8, be7d8938, b5c53fc0, fa015430, 20, 0) 0xfa4062a8(be7d8e28, be7d8938, b5c53fc0, fa013bc8, bd0ac0f0, ad0fee58) 0xfa226284(be7d8e40, be7d8938, b5c53fc0, bd0ac040, f6159f00, 1) 0xfa225fa0(be07f5a8, be7d8938, b5c53fc0, 1, f5c2a550, f5c2a550) 0xfa005b10(be035120, f660cb18, ad0ff0e8, fa015270, f661f5d0, ad0fefe8) 0xfa005fd8(be0281a0, f660cb18, ad0ff184, fa0156f0, f6226670, ad0ff080) 0xfa005fd8(be023b70, b6, 49, fa0156f0, f6159f00, ad0ff120) 0xfa005b10(be023b70, b7, ad0ff2e0, fa0137d8, 0, ad0ff1e8) 0xfa005b10(be023b70, f660cb18, ad0ff370, fa015430, 20, ad0ff280) 0xfa005fd8(be0741e0, f660cb18, ad0ff408, fa0156f0, bd0ac0f0, ad0ff310) 0xfa005fd8(be066d20, f660cb18, ad0ff4a0, fa0156f0, 42a165e0, ad0ff3a8) 0xfa005fd8(be05f6d0, f660cb18, ad0ff530, fa0156f0, 1, ad0ff440) 0xfa005fd8(be05a1b8, b6, ad0ff600, fa0156f0, f620a1f8, ad0ff4c0) 0xfa005b10(be05a1b8, b6, 0, fa015270, b6130000, ad0ff588) 0xfa005b10(be023af0, b6, 0, fa015270, f5c045c0, ad0ff630) 0xfa005b10(be0d4ed0, f65f5b80, ad0ff7d8, fa015270, f6d80ae8, ad0ff6c8) 0xfa00612c(be0ab2f0, f65f5b80, ad0ff7e0, fa0156f0, f6560da8, ad0ff778) 0xfa00612c(be0b84d0, b6, ad0ff8f8, fa0156f0, 0, ad0ff810) 0xfa005c64(be0b84d0, b6, ad0ff900, fa015270, f6560da8, ad0ff898) 0xfa005c64(be0af510, f5c1e740, ad0ffa24, fa015270, fa013848, ad0ff930) 0xfa00612c(be0ab2f0, b7, ad0ffaac, fa0156f0, 0, ad0ff9c0) 0xfa005c64(be0ab2f0, f5c1e740, ad0ffb2c, fa015430, 0, ad0ffa48) 0xfa00612c(b5d4ea98, f5c1e740, ad0ffba4, fa0156f0, 0, ad0ffad0) 0xfa00612c(ad0ffba8, 0, 0, fa0156f0, 3349f0, ad0ffb48) 0xfa000118(ad0ffc30, ad0ffe98, a, f5c1efd8, fa00aae0, ad0ffdb8) libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallAr
    guments_pnGThread__v_+0x274(ad0ffe90, ad0ffcf8, ad0ffdb0, aeed28, aeed28,
    ad0ffd08)
    libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle
    _4pnRJavaCallArguments_pnGThread__v_+0x164(feff0000, ae82b8, ad0ffda4, ad0ffda0 , ad0ffdb0, aeed28) libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsym
    bolHandle_5pnGThread__v_+0x60(ad0ffe90, ad0ffe8c, ad0ffe84, ad0ffe7c, ad0ffe74,
    aeed28)
    libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x128(aeed28, aeed28, af6758, ae82b8, 319508, fecd6a5c) libjvm.so`__1cKJavaThreadDrun6M_v_+0x288(aeed28, ffffffe2, ff00f808, ffff8000, 0 , 0) libjvm.so`_start+0x134(aeed28, 0, 0, 0, 0, 0) libthread.so.1`_lwp_start(0, 0, 0, 0, 0, 0)

    Hi there
    Not sure which jdk you are using but I am guessing you are using native code?
    libkernel32.so
    See http://java.sun.com/j2se/1.4.2/docs/guide/vm/signal-chaining.html
    Start your application this way, this should solve your problem.
    export LD_PRELOAD=<libjvm.so dir>/libjsig.so; java_application (ksh)
    setenv LD_PRELOAD <libjvm.so dir>/libjsig.so; java_application (csh)
    Also, even if u are using 1.3.1, u can get the libjsig.so from 1.4.2 and do the same.
    Hope this helps.

  • 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

Maybe you are looking for