Solaris 9 + Checkpoint R55 CORE DUMPING, HELP!

Here are the list of revisions I have installe donto the machine:
Solaris 9 (core install) (09/04)
Checkpoint R55 (HFA 15)
Recommended 9 (07/18/05).
When we are running the commands 'cpstart' and 'cpstop' the Solaris 9 OS follows by doing 2/3 core dumps each time. We have redone this box to check if its a fault with the install but it still core dumps each time with use the 'cpstart' and 'cpstop' commands to start and stop the Checkpoint R55 software.
>
# cpstop
Segmentation Fault (core dumped)
Segmentation Fault (core dumped)
VPN-1/FW-1 stopped
SVN Foundation: cpd stopped....... etc.
Has anyone got and ideas or suggestions?
its has been suggested to send this onto our Solaris VAR for interrogation to have the dumps put through some sort of analyser, but we have no support (media kit only) HELP!

we're also unable to connect to the box using the r55 checkpoint software (if anyone knows about this)
"....make sure your server is up and running and that you're defined as a GUI client".
it WAS working before appliying the Recommended_9 patch

Similar Messages

  • Using perl DBI on Solaris 10 gives core dump

    I am using perl 5.8.4 which comes along with Solaris 10.
    I have installed DBI-1.58.
    Even a test command is not working.
    perl -MDBI -e 'print "$DBI::VERSION\n";'
    Bus Error (core dumped)
    truss perl -MDBI -e 'print "$DBI::VERSION\n";'
    shows
    stat("/usr/local/lib/libc.so.1", 0xFFBFE5D0) Err#2 ENOENT
    mprotect(0xFEED0000, 104171, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
    mprotect(0xFEED0000, 104171, PROT_READ|PROT_EXEC) = 0
    munmap(0xFF370000, 8192) = 0
    brk(0x000A2470) = 0
    brk(0x000A4470) = 0
    brk(0x000A4470) = 0
    brk(0x000A6470) = 0
    brk(0x000A6470) = 0
    brk(0x000A8470) = 0
    brk(0x000A8470) = 0
    brk(0x000AA470) = 0
    brk(0x000AA470) = 0
    brk(0x000AC470) = 0
    Incurred fault #5, FLTACCESS %pc = 0xFEED44CC
    siginfo: SIGBUS BUS_ADRALN addr=0x00000001
    Received signal #10, SIGBUS [default]
    siginfo: SIGBUS BUS_ADRALN addr=0x00000001
    $perl -v
    command shows like its compiled with Intsize of 64 is this creating problem?
    Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
    Platform:
    osname=solaris, osvers=2.10, archname=sun4-solaris-64int
    uname='sunos localhost 5.10 sun4u sparc SUNW,Ultra-2'
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
    Compiler:
    cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO',
    optimize='-xO3 -xspace -xildoff',
    cppflags=''
    ccversion='Sun WorkShop', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=87654321
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
    Linker and Libraries:
    ld='cc', ldflags =''
    libpth=/lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -ldl -lm -lc
    perllibs=-lsocket -lnsl -ldl -lm -lc
    libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version=''
    Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R /usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE'
    cccdlflags='-KPIC', lddlflags='-G'
    Characteristics of this binary (from libperl):
    Compile-time options: USE_64_BIT_INT USE_LARGE_FILES
    Locally applied patches:
    22667 The optree builder was looping when constructing the ops ...
    22715 Upgrade to FileCache 1.04
    22733 Missing copyright in the README.
    22746 fix a coredump caused by rv2gv not fully converting a PV ...
    22755 Fix 29149 - another UTF8 cache bug hit by substr.
    22774 [perl #28938] split could leave an array without ...
    22775 [perl #29127] scalar delete of empty slice returned garbage
    22776 [perl #28986] perl -e "open m" crashes Perl
    22777 add test for change #22776 ("open m" crashes Perl)
    22778 add test for change #22746 ([perl #29102] Crash on assign ...
    22781 [perl #29340] Bizarre copy of ARRAY make sure a pad op's ...
    22796 [perl #29346] Double warning for int(undef) and abs(undef) ...
    22818 BOM-marked and (BOMless) UTF-16 scripts not working
    22823 [perl #29581] glob() misses a lot of matches
    22827 Smoke [5.9.2] 22818 FAIL(F) MSWin32 WinXP/.Net SP1 (x86/1 cpu)
    22830 [perl #29637] Thread creation time is hypersensitive
    22831 improve hashing algorithm for ptr tables in perl_clone: ...
    22839 [perl #29790] Optimization busted: '@a = "b", sort @a' ...
    22850 [PATCH] 'perl -v' fails if local_patches contains code snippets
    22852 TEST needs to ignore SCM files
    22886 Pod::Find should ignore SCM files and dirs
    22888 Remove redundant %SIG assignments from FileCache
    23006 [perl #30509] use encoding and "eq" cause memory leak
    23074 Segfault using HTML::Entities
    23106 Numeric comparison operators mustn't compare addresses of ...
    23320 [perl #30066] Memory leak in nested shared data structures ...
    23321 [perl #31459] Bug in read()
    Built under solaris
    Compiled at Jul 26 2005 05:26:55
    @INC:
    /usr/perl5/5.8.4/lib/sun4-solaris-64int
    /usr/perl5/5.8.4/lib
    /usr/perl5/site_perl/5.8.4/sun4-solaris-64int
    /usr/perl5/site_perl/5.8.4
    /usr/perl5/site_perl
    /usr/perl5/vendor_perl/5.8.4/sun4-solaris-64int
    /usr/perl5/vendor_perl/5.8.4
    /usr/perl5/vendor_perl
    Other details:
    file /usr/bin/perl
    /usr/bin/perl: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
    I tried installing DBI module using perlgcc also.
    perlgcc Makefile.PL
    make
    make test
    make install.
    $uname -a
    SunOS twirl 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-80
    Please help me out.

    Try this guy's list, he maintain an archive of Solaris package.
    http://www.ibiblio.org/pub/packages/solaris/sparc/html/creating.solaris.packages.html
    Of course, if you can get directly from Sun will be better.

  • Indecipherable core dump on Solaris x86_64

    On a 64-bit Solaris x86 machine (SunOS tempest-solaris 5.10 Generic_141445-09 i86pc i386 i86pc Solaris), I have been running gcc 4.3.4 (configured for i686-pc-solaris2.10) without a hitch. Both dbx 7.8 and gdb 7.1 are able to read core dumps created from a simple "goodbye, cruel world" program (kind of like "hello world", but it dereferences NULL at the end) built with gcc -m64 -g. However, with a more complex program, neither gdb nor dbx are able to figure it out core dumps (though they can debug it just fine if I set a breakpoint in main and start the program in the debugger).
    gdb's failure looks like this:
    GNU gdb (GDB) 7.1
    Copyright (C) 2010 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later
    <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-pc-solaris2.10".
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>...
    Reading symbols from
    /net/chronic2nas/emake-slothman-main-201006211520/out/i686_SunOS_64.5.10/ecloud/agent/ecagent...done.
    [New LWP 1]
    [New LWP 2]
    [New LWP 3]
    [New LWP 4]
    [New LWP 5]
    Reading symbols from /usr/lib/amd64/ld.so.1...(no debugging symbols
    found)...done.
    Loaded symbols for /usr/lib/amd64/ld.so.1
    Core was generated by `/opt/ecloud/i686_SunOS.5.10/bin/ecagent
    /opt/ecloud/i686_SunOS.5.10/bin/runagen'.
    Program terminated with signal 11, Segmentation fault.
    #0  0xfffffd7ffeac431c in ?? ()
    (gdb) bt
    #0  0xfffffd7ffeac431c in ?? ()
    Cannot access memory at address 0xfffffd7fffdfed30
    (gdb) thread 2
    [Switching to thread 2 (LWP 2)]#0  0xfffffd7ffeb2c8fa in ?? ()
    (gdb) bt
    #0  0xfffffd7ffeb2c8fa in ?? ()
    Cannot access memory at address 0xfffffd7ffe1f8dd8
    (gdb) thread 3
    [Switching to thread 3 (LWP 3)]#0  0xfffffd7ffeb27527 in ?? ()
    (gdb) bt
    #0  0xfffffd7ffeb27527 in ?? ()
    Cannot access memory at address 0xfffffd7ffdfffd68
    (gdb) thread 4
    [Switching to thread 4 (LWP 4)]#0  0xfffffd7ffeb27527 in ?? ()
    (gdb) bt
    #0  0xfffffd7ffeb27527 in ?? ()
    Cannot access memory at address 0xfffffd7ffde00e78
    (gdb) thread 5
    [Switching to thread 5 (LWP 5)]#0  0xfffffd7ffeb2c8fa in ?? ()
    (gdb) bt
    #0  0xfffffd7ffeb2c8fa in ?? ()
    Cannot access memory at address 0xfffffd7ffdbffc58
    (gdb) info sharedlibrary
    From                To                  Syms Read   Shared Object Library
    0xfffffd7fff3c1010  0xfffffd7fff3e614e  Yes (*)     /usr/lib/amd64/ld.so.1
    (*): Shared library is missing debugging information.and dbx's looks like this:
    Reading ecagent
    dbx: internal warning: writable memory segment 0x597000[28672] of size 0 in core
    dbx: internal warning: writable memory segment 0x59e000[3600384] of size 0 in core
    dbx: internal warning: writable memory segment 0xfffffd7ffd405000[4096] of size 0 in core
    dbx: internal warning: writable memory segment 0xfffffd7fff3fd000[8192] of size 0 in core
    dbx: internal warning: writable memory segment 0xfffffd7fffdfa000[24576] of size 0 in core
    core file header read successfully
    Reading ld.so.1
    dbx: core file read error: address 0xfffffd7fff3fb000 not available
    dbx: core file read error: address 0xfffffd7fff3fbae0 not available
    dbx: core file read error: address 0x598ff0 not available
    dbx: warning: Dbx could not initialize rtld_db
    Make sure this is the same version of Solaris where the core dump originated.
    Use `help core mismatch' for more info.
    (l@1) terminated by signal SEGV (no mapping at the fault address)
    0xffffffffffffffff:     <bad address 0xffffffffffffffff>
    (dbx) where
      [1] 0xfffffd7ffeac431c(0x0, 0x0, 0x784120, 0x170, 0x7, 0xffffffff), at 0xfffffd7ffeac431c
    (dbx) threads
    dbx: thread related commands not availableI get these errors even when debugging on the exact same machine where the core dump was generated. pstack is similarly confused:
    tempest-solaris% pstack /net/chronic2nas/emake-slothman-main-201006211520/logs-201006211902-solx2-ea2/core
    core '/net/chronic2nas/emake-slothman-main-201006211520/logs-201006211902-solx2-ea2/core' of 14854:     /opt/ecloud/i686_SunOS.5.10/bin/ecagent /opt/ecloud/i686_SunOS.5.10/bi
    -----------------  lwp# 1  --------------------------------
    fffffd7ffeac431c ???????? ()
    -----------------  lwp# 2  --------------------------------
    fffffd7ffeb2c8fa ???????? ()
    -----------------  lwp# 3  --------------------------------
    fffffd7ffeb27527 ???????? ()
    -----------------  lwp# 4  --------------------------------
    fffffd7ffeb27527 ???????? ()
    -----------------  lwp# 5  --------------------------------
    fffffd7ffeb2c8fa ???????? ()
    pstack: warning: librtld_db failed to initialize; symbols from shared libraries will not be availableAre there any arcane configuration parameters in Solaris that affect the generation of core dumps?

    Bother. Spoke too soon. One of my tests generated a readable core file, but the rest are having the same issues as detailed above. I am examining the core dump on the machine that generated it. The sizes of the failed tests are 21,522,239 and 21,485,375 and 21,526,447, so I doubt it’s running into a limit. (The successful one was 27,942,207.)
    On this machine, coreadm reports:
         global core file pattern:
         global core file content: all
           init core file pattern: core
           init core file content: all
                global core dumps: disabled
           per-process core dumps: enabled
          global setid core dumps: disabled
    per-process setid core dumps: disabled
         global core dump logging: disabledThe machine that got the successful core dump was physical while the ones where it failed were running under VMware LabManager, but I would be very surprised if that makes a difference to this matter. The successful core dump was generated by signal 9 (kill), while the bad ones have all been by signal 11 (segmentation fault).

  • XFree86 core dump

    Deal all:
    I use solaris x86 10/01, Tri3d 64 dx graphic card.
    And kdmconfig works well, CDE is ok.
    Because of third-party free software, I will try to
    use www.xfree86.org (XFree86).
    After installed (sh Xinstall.sh), following the instructions,
    tring to select graphic card, then.......
    Solaris show "Segment core dump" error message.
    What's wrong ??
    Somebody told me using the Solaris XFree86 Video Drivers and Porting Kit,
    but third-party software does not recognize.
    Help!!

    Hi,
    I have S3 Trio 3D /2X, Solaris 8 x86, x86 Poring Kit and XFREE86 version 4.1.0,
    It is working well with CDE....You might check wheter your card is supported by XFree86 and x86 porting kit from sun
    Regards
    Yuki

  • Core dump issue

    Hi
    I have a coredump file which was created on our production box. I am debugging that on my development machine.
    When i try the command
    dbx gwbgas dncore i am getting the output as given
    Reading gwbgas
    core file header read successfully
    Reading ld.so.1
    dbx: warning: Dbx could not initialize rtld_db
    Make sure this is the same version of Solaris where the core dump originated.
    Use `help core mismatch' for more info.
    program terminated by signal SEGV (no mapping at the fault address)
    0xffffffffffffffff: <bad address 0xffffffffffffffff>
    When i try where command i am getting the output as
    (dbx) where
    [1] 0xff2d071c(0x2a, 0x1617920, 0x5e4390, 0x0, 0x5b4d60, 0x801), at 0xff2d071b
    [2] lliomDisableOutputCallBack(0x400, 0x400, 0xa, 0x41ae30, 0xffbef748, 0x2a), at 0x19561c
    [3] lliomSelect(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x197054
    [4] lliomSelect(0x0, 0xea60, 0x15eec8, 0x0, 0x0, 0x0), at 0x197354
    [5] _lliomMapPollToSelect(0xba7b4, 0x15ec00, 0x15fc00, 0xf57, 0x38fc00, 0x44d400), at 0x198f4c
    [6] main(0x373000, 0xffbef9d4, 0xffbef9f0, 0x5, 0x265845, 0x0), at 0xba774
    This stack trace is not that meaningfull to me. Please help me to debug this further

    Since this is a mismatched core file, below is a snippet from Sun's "Debugging a program with dbx" document. Hope this helps.
    1. The shared libraries used by the program on the core-host may not be the same
    libraries as those on the dbx-host. To get proper stack traces involving the
    libraries, you’ll want to make these original libraries available on the dbx-host.
    2. dbx uses system libraries in /usr/lib to help understand the implementation
    details of the run time linker and threads library on the system. It may also be
    necessary to provide these system libraries from the core-host so that dbx can
    understand the runtime linker data structures and the threads data structures.

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

  • Help: dbx core dump, solaris 10, amd64

    Hi,
    Recently I run into the following when I debug a core dump,
    (dbx) where
    dbx: internal error: signal SIGSEGV (no mapping at the fault address)
    dbx's coredump will appear in /tmp
    Abort (core dumped)
    -bash-3.00$ dbx -V
    Sun Ceres DBX Debugger 7.7 SunOS_i386 2008/10/22
    For information about new features see `help changes'
    To remove this message, put `dbxenv suppress_startup_message 7.7' in your .dbxrc
    (dbx)
    I wonder if anyone has some idea of this bug, is it known? Is it fixed in sunstudio 12 u1?
    If needed, I can supply /tmp/core dumped by dbx.
    Thanks,

    -bash-3.00$ cat /etc/release
    Solaris 10 5/08 s10x_u5wos_10 X86
    Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
    Use is subject to license terms.
    Assembled 24 March 2008
    -bash-3.00$ pstack /tmp/core
    core '/tmp/core' of 11962: /z/tools/SUNWspro/bin/../prod/bin/amd64/dbx ./gp3310/bin/postgres core
    fffffd7fff1bc99a lwpkill () + a
    fffffd7fff161c89 raise () + 19
    fffffd7fff141210 abort () + 90
    0000000000565bb4 ???????? ()
    fffffd7fff1b7176 __sighndlr () + 6
    fffffd7fff1aba72 call_user_handler () + 252
    fffffd7fff1abc8e sigacthandler (b, fffffd7fffdfeef0, fffffd7fffdfeb90) + de
    --- called from signal handler with signal 11 (SIGSEGV) ---
    00000000007854a8 SUNWXUnw_Decode_FDE () + 324
    000000000078393b ???????? ()
    0000000000783a74 ???????? ()
    000000000060345d __1cLUnwindStackIdown_one6M_i_ () + 1d
    00000000005e7185 __1cFFramePunwind_down_one6MpnGPstack__b_ () + e1
    00000000005e77c8 __1cFFrameLcreate_next6FpnGPstack_i_p0_ () + 2e0
    0000000000677471 __1cGPstackRcreate_next_frame6M_pnFFrame__ () + 59
    0000000000677d00 __1cGPstackJwalkstack6MipnFFrame_bpF2pv_b3_2_ () + 78
    0000000000678bc1 __1cGPstackIwherecmd6Miibpv_v_ () + 221
    000000000060c9a5 __1cVDbxWhereCmdProcessingHprocess6Mippc_i_ () + 151
    000000000060ca5a __1cJksh_where6FpnGInterp_ippcpv_i_ () + 32
    000000000072f3ea ???????? ()
    000000000072ecfe __1cNpdksh_execute6FpnGInterp_pnCop_i_i_ () + 946
    000000000071d3ac __1cLpdksh_shell6FpnGInterp_pnGSource__i_ () + 468
    0000000000569254 __1cNmain_cmd_loop6FpnGInterp__v_ () + 9c
    0000000000569ba5 main () + 705
    000000000055defc ???????? ()
    Thanks,

  • 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

  • Report Server RTF on Solaris gives Core Dump

    We have Report Server 6.0.8.11.2 on Solaris.
    We are running reports thru URL and it is working fine for PDF and HTML. When we specify the desformat as RTF it gives Segmentation Fault Core dumped.
    We have tried using rwcli60 thru command line and it gives the same error, while PDF and HTML format is fine.
    Is there a patchset for Solaris for the same or are we missing on some parameter?
    - Tarun

    Hiya,
    Any resolution to this post , we have a native JNI call on a Websphere server running on Solaris 8 .. and same thing happening .. random core dump on the box ..
    No warning , no explanation
    Thanks so much for your help
    (btw . running Sun jvm 1.4.2_13)

  • Core dump on solaris 8/7 making JNI call.

    Hi,
    I am running solaris 8 and solaris 7 with Java 1.3.1. I have required solaris patches installed on the machine for java 1.3.1.
    From a C program I am making some JNI calls and when I run the program it core dumps at the very first JNI call. C program that make JNI calls are in a .so file.
    Same C code with Java 1.3.1 is running fine on window 2000, AIX 5.1, RedHat Advanced Server 2.1 and SuSE Enterprise Linux 7.
    Any help will be greatly appriciated.
    Thanks

    Hiya,
    Any resolution to this post , we have a native JNI call on a Websphere server running on Solaris 8 .. and same thing happening .. random core dump on the box ..
    No warning , no explanation
    Thanks so much for your help
    (btw . running Sun jvm 1.4.2_13)

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

  • Core Dump : Need Help

    Hi,
    I am porting the code to Forte 6.0 on Solaris 8.0.
    I am compiling the code using :
    -library=rwtools7,iostream options.
    While executing I get core dump. Following is the dbx description of the code.
    detected a multithreaded program
    t@1 (l@1) terminated by signal SEGV (no mapping at the fault address)
    Current function is unsafe_ostream::operator<<
    1211 outstr(_s, 0);
    (dbx) where
    current thread: t@1
    [1] ostream::flush(0x21000000, 0x21000000, 0x0, 0x0, 0x0, 0x0), at 0x2be54
    [2] unsafe_ostream::do_opfx(0x47488, 0x1, 0xffbef038, 0x1, 0xff3e260c, 0xff3e3b10), at 0x2a968
    [3] unsafe_ostream::outstr(0x47488, 0x46bd4, 0x0, 0x0, 0x47488, 0x46bd4), at 0x2ac50
    =>[4] unsafe_ostream::operator<<(this = 0x47488, _s = 0x46bd4 "GetAccessID() test passed"), line 1211 in "iostream.h"
    [5] ostream::operator<<(this = 0x47484, _s = 0x46bd4 "GetAccessID() test passed"), line 1350 in "iostream.h"
    [6] main(argc = 3, argv = 0xffbef2cc), line 35 in "AccessId.C"
    Can somebody help me to soty out this problem.

    The crash is caused by flush() which was given a bad argument value, i.e. 0x21000000. It seems to me do_opfx(), which prints out any prefix stuff, should not be called by outstr(). Instead outstr() should simply prints out the message "xxx test passed". Please make sure the code was linked with the right libs.
    - Rose

  • Core dump on solaris 10

    Hi,
    I have been getting a number of core dumps from an eclipse RCP based client java application. Its running on the following solaris box:
    SunOS 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-V240
    with following java configuration:
    java version "1.5.0_06"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
    Java HotSpot(TM) Server VM (build 1.5.0_06-b05, mixed mode)
    I have taken a pstack and am wondering can anyone help me as to the source of the problem:
    core 'core_client_20259_1196072158' of 20259:     client
    ----------------- lwp# 1 / thread# 1 --------------------
    fedc16e0 lwpkill (6, 0, feda4d20, ffffffff, fede8298, 6) + 8
    fed40158 abort (31330, 1, fb15ac34, a8244, fedeb298, 0) + 110
    fb02b268 ???????? (1, 51cc, 128de8, 1bc, fb154000, 5000) + fffffffffc2eb220
    fb0bc270 ???????? (0, fb172d90, 4000, fb02f43c, fb0c237e, fb02f43c) + fffffffffc37c228
    fae14284 JVM_handle_solaris_signal (b, ffbfecc0, ffbfea08, 5400, fb16db8c, 34500) + a38
    fedc0618 __sighndlr (b, ffbfecc0, ffbfea08, fae1382c, 0, 1) + c
    fedb5710 call_user_handler (b, ffbffeff, c, 0, fe6e2000, ffbfea08) + 3b8
    ff181784 render_icon_name_pixbuf (5e90c8, 5d36f0, 1, 0, 0, 6a5b50) + 13c
    ff18193c find_and_render_icon_source (a8efe0, 5d36f0, 1, 0, 6, 6a5b50) + 118
    ff181ba0 gtk_icon_set_render_icon (5d36f0, 1, 0, 0, 6a5b50, 0) + 158
    ff2b60b0 gtk_widget_render_icon (6a5b50, a8efe0, 6, 0, ffbfeeac, a85f4) + 170
    ff1be380 set_window_icon_from_stock (6a5b50, a8f020, 1c00, 233edc, ff369128, 200720) + 10
    ff1beb08 gtk_message_dialog_style_set (6a5b50, 0, 5b7e58, 19fa90, ff016818, ff35e53c) + 6c
    feffdcd8 g_closure_invoke (ffbff240, ffbff0d4, 2, 18000, 0, 5ae358) + 174
    ff01507c signal_emit_unlocked_R (1, ff03eaf8, feebee34, feebee20, ff03eae4, 5df670) + 724
    ff01442c g_signal_emit_valist (6a5b50, 2a44d, 5df670, ffbff474, ff03eaf8, feebee2c) + 7f8
    ff014738 g_signal_emit (6a5b50, f, 0, 0, 0, 33) + 1c
    ff2b57b4 gtk_widget_set_style_internal (6a5b50, 5d36f0, 9c00, 5d36f0, 5d36f0, ff2b4d40) + 198
    ff2b6068 gtk_widget_render_icon (6a5b50, ff330b8c, 6, 0, ff03ea00, a85f4) + 128
    ff1be380 set_window_icon_from_stock (6a5b50, ff330b8c, 5dd5c8, ffbff508, ffbff504, fefff3dc) + 10
    ff1be4a4 setup_type (6a5b50, 3, ffbff670, ff330b8c, ff1be514, ff35e53c) + 104
    ff001dcc g_object_constructor (8e0410, 5dec40, a8f1c8, 6a5b50, 2ed24, 1) + 214
    ff001158 g_object_newv (426358, ff001bb8, a8f1c0, 1, 8e0410, a8f1d8) + 328
    ff001b60 g_object_new_valist (0, 0, ffbff924, 0, 2, 6cea58) + 358
    ff000d30 g_object_new (426358, ff330a64, 3, ff330a98, 2, ff029800) + 60
    ff1be718 gtk_message_dialog_new (0, 2, 3, 2, 12cb0, 6a9018) + b4
    00012a10 displayMessage (88, 6a9018, 0, 10308, fd3f8c70, 307c8) + 6c
    fd3e3178 run (d, 6a9018, fd3f9380, 0, fd3f8a28, 0) + 728
    0001151c main (0, 23f60, ffbffac4, 22cb8, fe6d0488, fd3e2a50) + 308
    000111fc _start   (0, 0, 0, 0, 0, 0) + 108
    I have also taken an "mdb" stack:
    libc.so.1`_lwp_kill+8(6, 0, feda4d20, ffffffff, fede8298, 6)
    libc.so.1`abort+0x110(31330, 1, fb15ac34, a8244, fedeb298, 0)
    0xfb02b268(1, 51cc, 128de8, 1bc, fb154000, 5000)
    0xfb0bc270(0, fb172d90, 4000, fb02f43c, fb0c237e, fb02f43c)
    libjvm.so`JVM_handle_solaris_signal+0xa38(b, ffbfecc0, ffbfea08, 5400, fb16db8c, 34500)
    libc.so.1`__sighndlr+0xc(b, ffbfecc0, ffbfea08, fae1382c, 0, 1)
    libc.so.1`call_user_handler+0x3b8(b, ffbffeff, c, 0, fe6e2000, ffbfea08)
    libgtk-x11-2.0.so.0.400.9`render_icon_name_pixbuf+0x13c(5e90c8, 5d36f0, 1, 0, 0, 6a5b50)
    libgtk-x11-2.0.so.0.400.9`find_and_render_icon_source+0x118(a8efe0, 5d36f0, 1, 0, 6, 6a5b50)
    libgtk-x11-2.0.so.0.400.9`gtk_icon_set_render_icon+0x158(5d36f0, 1, 0, 0, 6a5b50, 0)
    libgtk-x11-2.0.so.0.400.9`gtk_widget_render_icon+0x170(6a5b50, a8efe0, 6, 0, ffbfeeac, a85f4)
    libgtk-x11-2.0.so.0.400.9`set_window_icon_from_stock+0x10(6a5b50, a8f020, 1c00, 233edc, ff369128, 200720)
    libgtk-x11-2.0.so.0.400.9`gtk_message_dialog_style_set+0x6c(6a5b50, 0, 5b7e58, 19fa90, ff016818, ff35e53c)
    libgobject-2.0.so.0.400.1`g_closure_invoke+0x174(ffbff240, ffbff0d4, 2, 18000, 0, 5ae358)
    libgobject-2.0.so.0.400.1`signal_emit_unlocked_R+0x724(1, ff03eaf8, feebee34, feebee20, ff03eae4, 5df670)
    libgobject-2.0.so.0.400.1`g_signal_emit_valist+0x7f8(6a5b50, 2a44d, 5df670, ffbff474, ff03eaf8, feebee2c)
    libgobject-2.0.so.0.400.1`g_signal_emit+0x1c(6a5b50, f, 0, 0, 0, 33)
    libgtk-x11-2.0.so.0.400.9`gtk_widget_set_style_internal+0x198(6a5b50, 5d36f0, 9c00, 5d36f0, 5d36f0, ff2b4d40)
    libgtk-x11-2.0.so.0.400.9`gtk_widget_render_icon+0x128(6a5b50, ff330b8c, 6, 0, ff03ea00, a85f4)
    libgtk-x11-2.0.so.0.400.9`set_window_icon_from_stock+0x10(6a5b50, ff330b8c, 5dd5c8, ffbff508, ffbff504, fefff3dc)
    libgtk-x11-2.0.so.0.400.9`setup_type+0x104(6a5b50, 3, ffbff670, ff330b8c, ff1be514, ff35e53c)
    libgobject-2.0.so.0.400.1`g_object_constructor+0x214(8e0410, 5dec40, a8f1c8, 6a5b50, 2ed24, 1)
    libgobject-2.0.so.0.400.1`g_object_newv+0x328(426358, ff001bb8, a8f1c0, 1, 8e0410, a8f1d8)
    libgobject-2.0.so.0.400.1`g_object_new_valist+0x358(0, 0, ffbff924, 0, 2, 6cea58)
    libgobject-2.0.so.0.400.1`g_object_new+0x60(426358, ff330a64, 3, ff330a98, 2, ff029800)
    libgtk-x11-2.0.so.0.400.9`gtk_message_dialog_new+0xb4(0, 2, 3, 2, 12cb0, 6a9018)
    displayMessage+0x6c(88, 6a9018, 0, 10308, fd3f8c70, 307c8)
    eclipse_1017.so`run+0x728(d, 6a9018, fd3f9380, 0, fd3f8a28, 0)
    main+0x308(0, 23f60, ffbffac4, 22cb8, fe6d0488, fd3e2a50)
    _start+0x108(0, 0, 0, 0, 0, 0)
    This certainly seems to point to the issue, but I dont know where to go from here.
    Thanks for any assistance
    /Trevor

    Hi,
    I have been getting a number of core dumps from an eclipse RCP based client java application. Its running on the following solaris box:
    SunOS 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-V240
    with following java configuration:
    java version "1.5.0_06"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
    Java HotSpot(TM) Server VM (build 1.5.0_06-b05, mixed mode)
    I have taken a pstack and am wondering can anyone help me as to the source of the problem:
    core 'core_client_20259_1196072158' of 20259:     client
    ----------------- lwp# 1 / thread# 1 --------------------
    fedc16e0 lwpkill (6, 0, feda4d20, ffffffff, fede8298, 6) + 8
    fed40158 abort (31330, 1, fb15ac34, a8244, fedeb298, 0) + 110
    fb02b268 ???????? (1, 51cc, 128de8, 1bc, fb154000, 5000) + fffffffffc2eb220
    fb0bc270 ???????? (0, fb172d90, 4000, fb02f43c, fb0c237e, fb02f43c) + fffffffffc37c228
    fae14284 JVM_handle_solaris_signal (b, ffbfecc0, ffbfea08, 5400, fb16db8c, 34500) + a38
    fedc0618 __sighndlr (b, ffbfecc0, ffbfea08, fae1382c, 0, 1) + c
    fedb5710 call_user_handler (b, ffbffeff, c, 0, fe6e2000, ffbfea08) + 3b8
    ff181784 render_icon_name_pixbuf (5e90c8, 5d36f0, 1, 0, 0, 6a5b50) + 13c
    ff18193c find_and_render_icon_source (a8efe0, 5d36f0, 1, 0, 6, 6a5b50) + 118
    ff181ba0 gtk_icon_set_render_icon (5d36f0, 1, 0, 0, 6a5b50, 0) + 158
    ff2b60b0 gtk_widget_render_icon (6a5b50, a8efe0, 6, 0, ffbfeeac, a85f4) + 170
    ff1be380 set_window_icon_from_stock (6a5b50, a8f020, 1c00, 233edc, ff369128, 200720) + 10
    ff1beb08 gtk_message_dialog_style_set (6a5b50, 0, 5b7e58, 19fa90, ff016818, ff35e53c) + 6c
    feffdcd8 g_closure_invoke (ffbff240, ffbff0d4, 2, 18000, 0, 5ae358) + 174
    ff01507c signal_emit_unlocked_R (1, ff03eaf8, feebee34, feebee20, ff03eae4, 5df670) + 724
    ff01442c g_signal_emit_valist (6a5b50, 2a44d, 5df670, ffbff474, ff03eaf8, feebee2c) + 7f8
    ff014738 g_signal_emit (6a5b50, f, 0, 0, 0, 33) + 1c
    ff2b57b4 gtk_widget_set_style_internal (6a5b50, 5d36f0, 9c00, 5d36f0, 5d36f0, ff2b4d40) + 198
    ff2b6068 gtk_widget_render_icon (6a5b50, ff330b8c, 6, 0, ff03ea00, a85f4) + 128
    ff1be380 set_window_icon_from_stock (6a5b50, ff330b8c, 5dd5c8, ffbff508, ffbff504, fefff3dc) + 10
    ff1be4a4 setup_type (6a5b50, 3, ffbff670, ff330b8c, ff1be514, ff35e53c) + 104
    ff001dcc g_object_constructor (8e0410, 5dec40, a8f1c8, 6a5b50, 2ed24, 1) + 214
    ff001158 g_object_newv (426358, ff001bb8, a8f1c0, 1, 8e0410, a8f1d8) + 328
    ff001b60 g_object_new_valist (0, 0, ffbff924, 0, 2, 6cea58) + 358
    ff000d30 g_object_new (426358, ff330a64, 3, ff330a98, 2, ff029800) + 60
    ff1be718 gtk_message_dialog_new (0, 2, 3, 2, 12cb0, 6a9018) + b4
    00012a10 displayMessage (88, 6a9018, 0, 10308, fd3f8c70, 307c8) + 6c
    fd3e3178 run (d, 6a9018, fd3f9380, 0, fd3f8a28, 0) + 728
    0001151c main (0, 23f60, ffbffac4, 22cb8, fe6d0488, fd3e2a50) + 308
    000111fc _start   (0, 0, 0, 0, 0, 0) + 108
    I have also taken an "mdb" stack:
    libc.so.1`_lwp_kill+8(6, 0, feda4d20, ffffffff, fede8298, 6)
    libc.so.1`abort+0x110(31330, 1, fb15ac34, a8244, fedeb298, 0)
    0xfb02b268(1, 51cc, 128de8, 1bc, fb154000, 5000)
    0xfb0bc270(0, fb172d90, 4000, fb02f43c, fb0c237e, fb02f43c)
    libjvm.so`JVM_handle_solaris_signal+0xa38(b, ffbfecc0, ffbfea08, 5400, fb16db8c, 34500)
    libc.so.1`__sighndlr+0xc(b, ffbfecc0, ffbfea08, fae1382c, 0, 1)
    libc.so.1`call_user_handler+0x3b8(b, ffbffeff, c, 0, fe6e2000, ffbfea08)
    libgtk-x11-2.0.so.0.400.9`render_icon_name_pixbuf+0x13c(5e90c8, 5d36f0, 1, 0, 0, 6a5b50)
    libgtk-x11-2.0.so.0.400.9`find_and_render_icon_source+0x118(a8efe0, 5d36f0, 1, 0, 6, 6a5b50)
    libgtk-x11-2.0.so.0.400.9`gtk_icon_set_render_icon+0x158(5d36f0, 1, 0, 0, 6a5b50, 0)
    libgtk-x11-2.0.so.0.400.9`gtk_widget_render_icon+0x170(6a5b50, a8efe0, 6, 0, ffbfeeac, a85f4)
    libgtk-x11-2.0.so.0.400.9`set_window_icon_from_stock+0x10(6a5b50, a8f020, 1c00, 233edc, ff369128, 200720)
    libgtk-x11-2.0.so.0.400.9`gtk_message_dialog_style_set+0x6c(6a5b50, 0, 5b7e58, 19fa90, ff016818, ff35e53c)
    libgobject-2.0.so.0.400.1`g_closure_invoke+0x174(ffbff240, ffbff0d4, 2, 18000, 0, 5ae358)
    libgobject-2.0.so.0.400.1`signal_emit_unlocked_R+0x724(1, ff03eaf8, feebee34, feebee20, ff03eae4, 5df670)
    libgobject-2.0.so.0.400.1`g_signal_emit_valist+0x7f8(6a5b50, 2a44d, 5df670, ffbff474, ff03eaf8, feebee2c)
    libgobject-2.0.so.0.400.1`g_signal_emit+0x1c(6a5b50, f, 0, 0, 0, 33)
    libgtk-x11-2.0.so.0.400.9`gtk_widget_set_style_internal+0x198(6a5b50, 5d36f0, 9c00, 5d36f0, 5d36f0, ff2b4d40)
    libgtk-x11-2.0.so.0.400.9`gtk_widget_render_icon+0x128(6a5b50, ff330b8c, 6, 0, ff03ea00, a85f4)
    libgtk-x11-2.0.so.0.400.9`set_window_icon_from_stock+0x10(6a5b50, ff330b8c, 5dd5c8, ffbff508, ffbff504, fefff3dc)
    libgtk-x11-2.0.so.0.400.9`setup_type+0x104(6a5b50, 3, ffbff670, ff330b8c, ff1be514, ff35e53c)
    libgobject-2.0.so.0.400.1`g_object_constructor+0x214(8e0410, 5dec40, a8f1c8, 6a5b50, 2ed24, 1)
    libgobject-2.0.so.0.400.1`g_object_newv+0x328(426358, ff001bb8, a8f1c0, 1, 8e0410, a8f1d8)
    libgobject-2.0.so.0.400.1`g_object_new_valist+0x358(0, 0, ffbff924, 0, 2, 6cea58)
    libgobject-2.0.so.0.400.1`g_object_new+0x60(426358, ff330a64, 3, ff330a98, 2, ff029800)
    libgtk-x11-2.0.so.0.400.9`gtk_message_dialog_new+0xb4(0, 2, 3, 2, 12cb0, 6a9018)
    displayMessage+0x6c(88, 6a9018, 0, 10308, fd3f8c70, 307c8)
    eclipse_1017.so`run+0x728(d, 6a9018, fd3f9380, 0, fd3f8a28, 0)
    main+0x308(0, 23f60, ffbffac4, 22cb8, fe6d0488, fd3e2a50)
    _start+0x108(0, 0, 0, 0, 0, 0)
    This certainly seems to point to the issue, but I dont know where to go from here.
    Thanks for any assistance
    /Trevor

  • Core Dump on Solaris 10 (Signal 10 - Bus Error), but not on Solaris 8?

    Hi,
    We just moved our product from Solaris 8 to Solaris 10. It runs for months on Solaris 8 without any problems, while core dumped after running about 2 weeks on Solaris 10.
    Any clue on what could be wrong is apprecaited.
    pam

    Hi Andrew,
    Appreciate your answer very much. I am very new to Solaris and UNIX in general. Would you please let me know what kind of info would help diagnose the
    problem? I have stack pointer, output of "where" from gdb. frme pointer, etc.
    pam
    ===================
    GNU gdb 6.3
    Copyright 2004 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB. Type "show warranty" for details.
    This GDB was configured as "sparc-sun-solaris2.8"...(no debugging symbols found)
    Core was generated by `./warnsrvr'.
    Program terminated with signal 10, Bus error.
    #0 0x001a3ca8 in __1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__ ()
    (gdb) where
    #0 0x001a3ca8 in __1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__ ()
    #1 0x001a3ca8 in __1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__ ()
    Previous frame identical to this frame (corrupt stack?)
    ======================================
    (gdb) disassemble 0x001a3ca8
    Dump of assembler code for function __1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__:
    0x001a3c24 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+0>: cmp %o0, 1
    0x001a3c28 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+4>: be,pn %icc, 0x1a3c38 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+20>
    0x001a3c2c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+8>: sethi %hi(0x572000), %l6
    0x001a3c30 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+12>: ret
    0x001a3c34 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+16>: restore %g0, 0, %o0
    0x001a3c38 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+20>: ld [ %l6 + 0x358 ], %l5
    0x001a3c3c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+24>: cmp %l5, 0
    0x001a3c40 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+28>: bne,pn %icc, 0x1a3c50 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+44>
    0x001a3c44 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+32>: cmp %l5, 1
    0x001a3c48 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+36>: ret
    0x001a3c4c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+40>: restore %g0, 1, %o0
    0x001a3c50 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+44>: bne,pn %icc, 0x1a3cb0 <__1cSWPReferenceManagerOInputIonoModel6MrknKIONO_MODEL_khki_nGRESULT__+4>
    0x001a3c54 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+48>: sethi %hi(0x1a3c00), %l7
    0x001a3c58 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+52>: mov -1, %i1
    0x001a3c5c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+56>: sth %i1, [ %fp + -1864 ]
    0x001a3c60 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+60>: add %fp, -1824, %o0
    0x001a3c64 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+64>: ldd [ %l7 + 8 ], %f0
    0x001a3c68 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+68>: call 0x1c87f0 <___const_seg_900001301+16>
    0x001a3c6c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+72>: std %f0, [ %fp + -1856 ]
    0x001a3c70 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+76>: call 0x1cf888 <__1cKIono2Ascii6FrknKIONO_MODEL_pcki_v_+100>
    0x001a3c74 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+80>: add %fp, -1864, %o0
    0x001a3c78 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+84>: sllx %i2, 0x30, %o1
    0x001a3c7c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+88>: mov %i0, %o0
    0x001a3c80 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+92>: srax %o1, 0x30, %o1
    0x001a3c84 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+96>: call 0x182cb0 <__1cTGenReferenceManagerOGetCorrections6MrknKCLSGpsTime_rknICLSCoord_rnOCORRECTION_SET__nGRESULT__+3504>
    0x001a3c88 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+100>: add %fp, -1864, %o2
    0x001a3c8c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+104>: cmp %o0, 1
    0x001a3c90 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+108>: be,pn %icc, 0x1a3ca0 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+124>
    0x001a3c94 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+112>: mov %i0, %o0
    0x001a3c98 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+116>: ret
    0x001a3c9c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+120>: restore %g0, 0, %o0
    0x001a3ca0 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+124>: call 0x1a7068 <__1cSWPReferenceManagerPAdjustXTRATimes6MpnZCLSGnssSatellitePredictor_khrnKCLSGpsTime_rd_nGRESULT__+3584>
    0x001a3ca4 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+128>: add %fp, -1864, %o1
    0x001a3ca8 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+132>: ret
    End of assembler dump.
    =====================================
    (gdb) info registers
    g0 0x0 0
    g1 0xfd77ecb8 -42472264
    g2 0x11 17
    g3 0xecf0 60656
    g4 0xfd77e304 -42474748
    g5 0xfc 252
    g6 0x0 0
    g7 0xfeda4200 -19250688
    o0 0x1 1
    o1 0x20 32
    o2 0x693500 6894848
    o3 0xecf0 60656
    o4 0x6a21f0 6955504
    o5 0x1 1
    sp 0xfd77ec38 0xfd77ec38
    o7 0x1a3ca0 1719456
    l0 0x1b000021 452984865
    l1 0x2ca2a40 46803520
    l2 0x40173076 1075261558
    l3 0x57d22e16 1473392150
    l4 0x3fa80492 1067975826
    l5 0x3c06fe49 1007091273
    l6 0x4072b4a5 1081259173
    l7 0x410d711d 1091399965
    i0 0x421c0000 1109131264
    i1 0xffffffff -1
    i2 0x1d000018 486539288
    i3 0x2ca2808 46802952
    i4 0x40138e4a 1075023434
    i5 0x8b122e16 -1961742826
    fp 0xbfb17c3b 0xbfb17c3b
    i7 0xa817f0db -1474826021
    y 0x3 3
    psr 0xfe401007 -29356025
    wim 0x0 0
    tbr 0x0 0
    pc 0x1a3ca8 0x1a3ca8 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+132>
    npc 0x1a3cac 0x1a3cac <__1cSWPReferenceManagerOInputIonoModel6MrknKIONO_MODEL_khki_nGRESULT__>
    fsr 0x400420 4195360
    csr 0x0 0

  • Weblogic Core Dumps on Solaris with Hotspot Server VM

    For Sun Microsystems SPARC with Solaris 2.7 the supported platform is
    "SunSoft SDK 1.3.1 JavaTM 2 Runtime Environment, Standard Edition (build
    1.3.1-b24) Java HotSpotTM Server VM (build 1.3.1-b24, mixed mode)"
    We have set the MaxPermSize as specified below and are still receiving
    periodic core dumps in a production environment. The most recent of which
    is "Unexpected Signal : 11 occurred at PC=0xee4b5d00 Function
    name=JVM_CurrentTimeMillis" a reported bug on Sun's bug parade (Bug Id
    #4488864). Are there some other settings that we should try? Is there a
    more stable VM we should be using like "SunSoft SDK 1.3.0 JavaTM 2 Runtime
    Environment, Standard Edition (build 1.3.0) "?
    Help would be appreciated,
    Thanks
    Problems with JDK 1.3 crashing
    If you have problems with OutOfMemory errors and the JVM crashing with JDK
    1.3, try setting: -XX:MaxPermSize=128m. There is currently an open bug on
    Sun's bug parade that describes this problem. See,
    http://developer.java.sun.com/developer/bugParade/bugs/4390238.html

    FYI: Stability seems to have been achieved by setting:
    -XX:MaxNewSize=64m
    -XX:MaxPermSize=128m
    "Paul Hamill" <[email protected]> wrote in message
    news:[email protected]..
    Unfortunately we tried switching to client and we still periodically getthe
    core dumps.
    "Dimitri Rakitine" <[email protected]> wrote in message
    news:[email protected]..
    I'd be interested to know this as well - so far the only stable option
    that I know of is to use client JVM. Server Hotspot crashes, sooner
    or later. 1.3.1-b24 server crashes as well, but not the client JVM.
    Paul Hamill <[email protected]> wrote:
    For Sun Microsystems SPARC with Solaris 2.7 the supported platform is
    "SunSoft SDK 1.3.1 JavaTM 2 Runtime Environment, Standard Edition
    (build
    1.3.1-b24) Java HotSpotTM Server VM (build 1.3.1-b24, mixed mode)"
    We have set the MaxPermSize as specified below and are still receiving
    periodic core dumps in a production environment. The most recent of
    which
    is "Unexpected Signal : 11 occurred at PC=0xee4b5d00 Function
    name=JVM_CurrentTimeMillis" a reported bug on Sun's bug parade (Bug Id
    #4488864). Are there some other settings that we should try? Is
    there
    a
    more stable VM we should be using like "SunSoft SDK 1.3.0 JavaTM 2Runtime
    Environment, Standard Edition (build 1.3.0) "?
    Help would be appreciated,
    Thanks
    Problems with JDK 1.3 crashing
    If you have problems with OutOfMemory errors and the JVM crashing with
    JDK
    1.3, try setting: -XX:MaxPermSize=128m. There is currently an open bugon
    Sun's bug parade that describes this problem. See,
    http://developer.java.sun.com/developer/bugParade/bugs/4390238.html
    Dimitri

Maybe you are looking for

  • Can I force a Flexconnect AP into Standalone mode?

    I've found an interesting setup where some remote sites have over 400+ ms latency to the controller (This is due to the 3G/4G WWAN connection back to corp), I am thinking this causing some issues since the required latency for Flexconnect is no more

  • Groups and Authorization

    Hello, I'm looking for the best way to use groups as a means to authorize. I have set up groups such as 'Group A', 'Group B', and I tried to set up a PL/SQL authorization scheme as follows: wwv_flow_user_api.current_user_in_group('Group A') But the P

  • Outgoing mail appearing in Today smart folder

    This isn't a major issue - however - I use smart folders in Mail and whenever I send out an email (reply or otherwise) that email temporarily shows up in the Today smart mailbox as it's being sent before being placed in the Sent folder. Any thougths

  • Creative Cloud - Dreamweaver won't download!

    I click on the "More Information" link and it says "Error Code: 6". I work for an auction company and my desktop died, so I switched to another computer that didn't have Dreamweaver on it. The OS is Windows 7. I logged in to Adobe just fine, download

  • Pull list shortage qty list

    Dear PP Gurus,                       In Rem make to stock scenario, we stage the missing parts through pull list, In this report system shows shortage qty and available qty at prod storage location.                         But our client want to see