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 its 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). -
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 -
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 furtherSince 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, youll 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?
- TarunHiya,
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.
ThanksHiya,
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. -
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 -
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
/TrevorHi,
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.
pamHi 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.htmlFYI: 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
-
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
-
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