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)

Similar Messages

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

Zfs core dumps in Solaris Zones after patchcluster installation

Hi
I've installed the recommended patch cluster for Solaris 10 (SPARC) on my T2000 Server.
Now after the reboot all the Solaris Zones (got about 10 of them) instantly do zfs core dumps when their booted.
Some Output:
Dec 15 15:34:43 XXXXX genunix: NOTICE: core_log: zfs[1711] core dumped: /var/core/core_XXXXXX_zfs_0_0_1292423682_1711
bash-3.00# svcs
STATE STIME FMRI
online 13:58:50 svc:/system/svc/restarter:default
online 13:58:51 svc:/system/filesystem/root:default
online 13:58:51 svc:/network/loopback:default
online 13:58:53 svc:/network/pfil:default
online 13:58:54 svc:/system/installupdates:default
online 13:58:55 svc:/system/boot-archive:default
online 13:58:56 svc:/network/physical:default
online 13:58:57 svc:/system/filesystem/usr:default
online 13:58:57 svc:/system/identity:node
online 13:58:58 svc:/system/device/local:default
online 13:58:58 svc:/system/keymap:default
online 13:58:58 svc:/milestone/devices:default
online 13:58:58 svc:/system/filesystem/minimal:default
online 13:58:58 svc:/system/rmtmpfiles:default
online 13:58:58 svc:/system/cryptosvc:default
online 13:58:59 svc:/system/identity:domain
online 13:58:59 svc:/system/name-service-cache:default
online 13:58:59 svc:/system/coreadm:default
online 13:58:59 svc:/network/ipsec/ipsecalgs:default
online 13:58:59 svc:/application/print/ppd-cache-update:default
online 13:58:59 svc:/network/ipsec/policy:default
online 13:59:00 svc:/milestone/network:default
online 13:59:00 svc:/network/initial:default
online 13:59:00 svc:/system/manifest-import:default
online 13:59:00 svc:/network/service:default
online 13:59:00 svc:/milestone/single-user:default
online 13:59:00 svc:/network/dns/client:default
online 13:59:00 svc:/network/routing-setup:default
online 13:59:00 svc:/milestone/name-services:default
online 13:59:03 svc:/milestone/sysconfig:default
online 13:59:03 svc:/system/utmp:default
online 13:59:03 svc:/system/console-login:default
offline 13:58:51 svc:/system/sysidtool:net
offline 13:58:51 svc:/network/rpc/bind:default
offline 13:58:51 svc:/system/sysidtool:system
offline 13:58:52 svc:/network/nfs/status:default
offline 13:58:52 svc:/network/nfs/nlockmgr:default
offline 13:58:52 svc:/network/nfs/cbd:default
offline 13:58:52 svc:/network/nfs/mapid:default
offline 13:58:52 svc:/network/inetd:default
offline 13:58:52 svc:/network/nfs/client:default
offline 13:58:52 svc:/system/filesystem/autofs:default
offline 13:58:53 svc:/system/system-log:default
offline 13:58:53 svc:/network/smtp:sendmail
offline 13:58:53 svc:/system/cron:default
offline 13:58:53 svc:/milestone/multi-user:default
offline 13:58:54 svc:/application/management/snmpdx:default
offline 13:58:54 svc:/application/management/dmi:default
offline 13:58:54 svc:/application/management/seaport:default
offline 13:58:54 svc:/network/ssh:default
offline 13:58:54 svc:/milestone/multi-user-server:default
offline 13:58:54 svc:/application/font/fc-cache:default
offline 13:58:55 svc:/application/management/sma:default
offline 13:58:58 svc:/system/sac:default
offline 13:59:00 svc:/network/shares/group:default
offline 13:59:00 svc:/system/boot-archive-update:default
maintenance 15:34:43 svc:/system/filesystem/local:default
uninitialized 13:58:52 svc:/network/rpc/gss:default
uninitialized 13:58:54 svc:/application/font/stfsloader:default
uninitialized 13:58:55 svc:/network/rpc/rstat:default
uninitialized 13:58:55 svc:/application/print/rfc1179:default
uninitialized 13:58:55 svc:/application/x11/xfs:default
uninitialized 13:58:55 svc:/network/finger:default
uninitialized 13:58:55 svc:/network/ftp:default
uninitialized 13:58:56 svc:/network/login:rlogin
uninitialized 13:58:56 svc:/network/nfs/rquota:default
uninitialized 13:58:56 svc:/network/rpc/rusers:default
uninitialized 13:58:56 svc:/network/rpc/smserver:default
uninitialized 13:58:57 svc:/network/security/ktkt_warn:default
uninitialized 13:58:57 svc:/network/shell:default
uninitialized 13:58:57 svc:/network/telnet:default
uninitialized 13:58:58 svc:/network/rpc-100235_1/rpc_ticotsord:default
uninitialized 13:58:58 svc:/network/rpc/cde-calendar-manager:default
uninitialized 13:58:59 svc:/network/rpc/cde-ttdbserver:tcp
bash-3.00# svcs -x
svc:/system/filesystem/local:default (local file system mounts)
State: maintenance since Wed Dec 15 15:34:43 2010
Reason: Start method exited with $SMF_EXIT_ERR_FATAL.
See: http://sun.com/msg/SMF-8000-KS
See: /var/svc/log/system-filesystem-local:default.log
Impact: 24 dependent services are not running. (Use -v for list.)
svc:/network/rpc/gss:default (Generic Security Service)
State: uninitialized since Wed Dec 15 13:58:52 2010
Reason: Restarter svc:/network/inetd:default is not running.
See: http://sun.com/msg/SMF-8000-5H
See: gssd(1M)
Impact: 11 dependent services are not running. (Use -v for list.)
svc:/network/rpc/rstat:default (kernel statistics server)
State: uninitialized since Wed Dec 15 13:58:55 2010
Reason: Restarter svc:/network/inetd:default is not running.
See: http://sun.com/msg/SMF-8000-5H
See: rpc.rstatd(1M)
See: rstatd(1M)
Impact: 1 dependent service is not running. (Use -v for list.)
bash-3.00# cat /var/svc/log/system-filesystem-local:default.log
[ Jul 10 03:41:35 Enabled. ]
[ Jul 10 03:43:45 Rereading configuration. ]
[ Jul 10 03:44:17 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 10 03:44:18 Method "start" exited with status 0 ]
[ Jul 10 12:44:36 Enabled. ]
[ Jul 10 12:44:45 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 10 12:44:45 Method "start" exited with status 0 ]
[ Jul 10 12:45:03 Enabled. ]
[ Jul 10 12:45:09 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 10 12:45:09 Method "start" exited with status 0 ]
[ Jul 10 13:54:39 Enabled. ]
[ Jul 10 13:54:46 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 10 13:54:46 Method "start" exited with status 0 ]
[ Jul 18 12:34:19 Enabled. ]
[ Jul 18 12:34:27 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 18 12:34:27 Method "start" exited with status 0 ]
[ Jul 18 17:29:08 Enabled. ]
[ Jul 18 17:29:15 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 18 17:29:15 Method "start" exited with status 0 ]
[ Jul 19 11:13:34 Enabled. ]
[ Jul 19 11:13:42 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 19 11:13:42 Method "start" exited with status 0 ]
[ Jul 19 11:32:23 Enabled. ]
[ Jul 19 11:32:30 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 19 11:32:31 Method "start" exited with status 0 ]
[ Jul 19 11:57:06 Enabled. ]
[ Jul 19 11:57:13 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 19 11:57:13 Method "start" exited with status 0 ]
[ Jul 19 12:40:05 Enabled. ]
[ Jul 19 12:40:12 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 19 12:40:12 Method "start" exited with status 0 ]
[ Jul 20 15:51:46 Enabled. ]
[ Jul 20 15:51:54 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 20 15:51:54 Method "start" exited with status 0 ]
[ Jul 24 11:42:17 Enabled. ]
[ Jul 24 11:42:25 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 24 11:42:25 Method "start" exited with status 0 ]
[ Jul 27 12:05:06 Stopping because service disabled. ]
[ Jul 27 12:05:07 Executing stop method (null) ]
[ Jul 27 12:13:10 Enabled. ]
[ Jul 27 12:13:17 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 27 12:13:17 Method "start" exited with status 0 ]
[ Jul 27 13:10:26 Stopping because service disabled. ]
[ Jul 27 13:10:26 Executing stop method (null) ]
[ Jul 27 13:18:19 Enabled. ]
[ Jul 27 13:18:26 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 27 13:18:26 Method "start" exited with status 0 ]
[ Jul 31 10:12:31 Enabled. ]
[ Jul 31 10:12:38 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jul 31 10:12:39 Method "start" exited with status 0 ]
[ Aug 7 10:08:52 Stopping because service disabled. ]
[ Aug 7 10:08:52 Executing stop method (null) ]
[ Aug 7 10:34:50 Enabled. ]
[ Aug 7 10:34:57 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 7 10:34:58 Method "start" exited with status 0 ]
[ Aug 9 09:14:50 Stopping because service disabled. ]
[ Aug 9 09:14:50 Executing stop method (null) ]
[ Aug 9 09:55:03 Enabled. ]
[ Aug 9 09:55:10 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 9 09:55:11 Method "start" exited with status 0 ]
[ Aug 16 10:46:43 Enabled. ]
[ Aug 16 10:46:50 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 16 10:46:50 Method "start" exited with status 0 ]
[ Aug 16 12:06:56 Enabled. ]
[ Aug 16 12:07:02 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 16 12:07:02 Method "start" exited with status 0 ]
[ Aug 16 13:45:10 Enabled. ]
[ Aug 16 13:45:16 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 16 13:45:16 Method "start" exited with status 0 ]
[ Aug 16 14:36:59 Enabled. ]
[ Aug 16 14:37:07 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 16 14:37:07 Method "start" exited with status 0 ]
[ Aug 16 15:00:40 Enabled. ]
[ Aug 16 15:00:47 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 16 15:00:47 Method "start" exited with status 0 ]
[ Aug 22 16:00:13 Enabled. ]
[ Aug 22 16:00:21 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 22 16:00:21 Method "start" exited with status 0 ]
[ Aug 23 09:49:04 Enabled. ]
[ Aug 23 09:49:10 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 23 09:49:11 Method "start" exited with status 0 ]
[ Aug 23 09:49:23 Stopping because service disabled. ]
[ Aug 23 09:49:23 Executing stop method (null) ]
[ Aug 23 10:04:13 Enabled. ]
[ Aug 23 10:04:20 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 23 10:04:20 Method "start" exited with status 0 ]
[ Aug 23 10:06:57 Enabled. ]
[ Aug 23 10:07:04 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 23 10:07:05 Method "start" exited with status 0 ]
[ Oct 23 08:43:05 Enabled. ]
[ Oct 23 08:43:14 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Oct 23 08:43:14 Method "start" exited with status 0 ]
[ Nov 21 14:51:50 Enabled. ]
[ Nov 21 14:51:58 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Nov 21 14:51:59 Method "start" exited with status 0 ]
[ Nov 29 15:33:19 Enabled. ]
[ Nov 29 15:33:26 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Nov 29 15:33:27 Method "start" exited with status 0 ]
[ Dec 18 13:37:35 Enabled. ]
[ Dec 18 13:37:42 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Dec 18 13:37:42 Method "start" exited with status 0 ]
[ Dec 19 08:48:07 Enabled. ]
[ Dec 19 08:48:14 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Dec 19 08:48:14 Method "start" exited with status 0 ]
[ Dec 19 08:56:07 Enabled. ]
[ Dec 19 08:56:14 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Dec 19 08:56:14 Method "start" exited with status 0 ]
[ Dec 19 08:57:41 Enabled. ]
[ Dec 19 08:57:48 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Dec 19 08:57:48 Method "start" exited with status 0 ]
[ Feb 1 10:39:48 Enabled. ]
[ Feb 1 10:39:55 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Feb 1 10:39:56 Method "start" exited with status 0 ]
[ Feb 8 11:12:50 Enabled. ]
[ Feb 8 11:12:57 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Feb 8 11:12:57 Method "start" exited with status 0 ]
[ Jun 6 10:08:34 Enabled. ]
[ Jun 6 10:08:44 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Jun 6 10:08:46 Method "start" exited with status 0 ]
[ Aug 8 09:45:48 Enabled. ]
[ Aug 8 09:46:35 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 8 09:46:36 Method "start" exited with status 0 ]
[ Aug 14 17:53:59 Enabled. ]
[ Aug 14 17:54:06 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 14 17:54:06 Method "start" exited with status 0 ]
[ Aug 14 17:55:20 Enabled. ]
[ Aug 14 17:55:27 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 14 17:55:27 Method "start" exited with status 0 ]
[ Aug 18 15:19:17 Enabled. ]
[ Aug 18 15:19:24 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 18 15:19:24 Method "start" exited with status 0 ]
[ Aug 29 12:56:48 Enabled. ]
[ Aug 29 12:56:55 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 29 12:56:55 Method "start" exited with status 0 ]
[ Oct 13 11:59:43 Enabled. ]
[ Oct 13 11:59:50 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Oct 13 11:59:51 Method "start" exited with status 0 ]
[ Feb 26 16:47:00 Enabled. ]
[ Feb 26 16:47:07 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Feb 26 16:47:07 Method "start" exited with status 0 ]
[ Apr 14 15:54:17 Enabled. ]
[ Apr 14 15:54:24 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Apr 14 15:54:25 Method "start" exited with status 0 ]
[ Aug 28 08:49:58 Stopping because service disabled. ]
[ Aug 28 08:49:58 Executing stop method (null) ]
[ Aug 28 08:52:54 Enabled. ]
[ Aug 28 08:53:01 Executing start method ("/lib/svc/method/fs-local") ]
bootadm: this operation is not supported on sparc
[ Aug 28 08:53:01 Method "start" exited with status 0 ]
[ Aug 28 09:08:20 Stopping because service disabled. ]
[ Aug 28 09:08:20 Executing stop method (null) ]
[ Sep 1 16:05:36 Enabled. ]
[ Sep 1 16:06:05 Executing start method ("/lib/svc/method/fs-local") ]
[ Sep 1 16:06:05 Method "start" exited with status 0 ]
[ Sep 1 19:29:19 Enabled. ]
[ Sep 1 19:29:27 Executing start method ("/lib/svc/method/fs-local") ]
[ Sep 1 19:29:27 Method "start" exited with status 0 ]
[ Sep 1 23:04:00 Enabled. ]
[ Sep 1 23:04:08 Executing start method ("/lib/svc/method/fs-local") ]
[ Sep 1 23:04:08 Method "start" exited with status 0 ]
[ Sep 2 00:23:41 Stopping because service disabled. ]
[ Sep 2 00:23:42 Executing stop method (null) ]
[ Sep 2 00:46:46 Enabled. ]
[ Sep 2 00:46:53 Executing start method ("/lib/svc/method/fs-local") ]
[ Sep 2 00:46:54 Method "start" exited with status 0 ]
[ Sep 26 12:04:34 Enabled. ]
[ Sep 26 12:04:41 Executing start method ("/lib/svc/method/fs-local") ]
[ Sep 26 12:04:42 Method "start" exited with status 0 ]
[ Oct 20 13:05:09 Stopping because service disabled. ]
[ Oct 20 13:05:10 Executing stop method (null) ]
[ Oct 20 13:24:01 Enabled. ]
[ Oct 20 13:24:08 Executing start method ("/lib/svc/method/fs-local") ]
[ Oct 20 13:24:09 Method "start" exited with status 0 ]
[ Oct 21 16:30:59 Enabled. ]
[ Oct 21 16:31:09 Executing start method ("/lib/svc/method/fs-local") ]
[ Oct 21 16:31:09 Method "start" exited with status 0 ]
[ Oct 21 16:32:42 Stopping because service disabled. ]
[ Oct 21 16:32:42 Executing stop method (null) ]
[ Oct 21 16:42:05 Enabled. ]
[ Oct 21 16:42:15 Executing start method ("/lib/svc/method/fs-local") ]
[ Oct 21 16:42:15 Method "start" exited with status 0 ]
[ Oct 21 17:27:37 Enabled. ]
[ Oct 21 17:27:47 Executing start method ("/lib/svc/method/fs-local") ]
[ Oct 21 17:27:47 Method "start" exited with status 0 ]
[ Oct 22 11:08:34 Enabled. ]
[ Oct 22 11:08:43 Executing start method ("/lib/svc/method/fs-local") ]
[ Oct 22 11:08:43 Method "start" exited with status 0 ]
[ Dec 9 09:17:33 Stopping because service disabled. ]
[ Dec 9 09:17:33 Executing stop method (null) ]
[ Dec 10 11:47:14 Enabled. ]
[ Dec 10 11:47:24 Executing start method ("/lib/svc/method/fs-local") ]
[ Dec 10 11:47:25 Method "start" exited with status 0 ]
[ Dec 15 10:52:25 Stopping because service disabled. ]
[ Dec 15 10:52:25 Executing stop method (null) ]
[ Dec 15 12:42:16 Enabled. ]
[ Dec 15 12:42:26 Executing start method ("/lib/svc/method/fs-local") ]
Abort - core dumped
WARNING: /usr/sbin/zfs mount -a failed: exit status 134
[ Dec 15 12:42:28 Method "start" exited with status 95 ]
[ Dec 15 13:13:19 Enabled. ]
[ Dec 15 13:13:28 Executing start method ("/lib/svc/method/fs-local") ]
Abort - core dumped
WARNING: /usr/sbin/zfs mount -a failed: exit status 134
[ Dec 15 13:13:30 Method "start" exited with status 95 ]
[ Dec 15 13:58:51 Enabled. ]
[ Dec 15 13:59:00 Executing start method ("/lib/svc/method/fs-local") ]
Abort - core dumped
WARNING: /usr/sbin/zfs mount -a failed: exit status 134
[ Dec 15 13:59:03 Method "start" exited with status 95 ]
[ Dec 15 15:34:41 Leaving maintenance because clear requested. ]
[ Dec 15 15:34:41 Enabled. ]
[ Dec 15 15:34:41 Executing start method ("/lib/svc/method/fs-local") ]
Abort - core dumped
WARNING: /usr/sbin/zfs mount -a failed: exit status 134
[ Dec 15 15:34:43 Method "start" exited with status 95 ]
bash-3.00# /usr/sbin/zfs mount -a
internal error: Unknown error
Abort (core dumped)
Before that I've installed the patch cluster with halted solaris zones which produced following output:
Application of patches finished : 2010.12.15 12:08:43
Following patches were applied :
119254-77 119812-10 125719-31 140159-03 142911-01
141588-04 119900-11 125731-05 142292-01 142933-02
142251-02 119906-16 126206-05 141444-09 142909-17
118666-28 120460-17 126363-08 141500-07 143140-04
118667-28 121012-03 126365-16 141502-02 143502-01
118777-16 121308-20 126868-04 141506-09 143506-01
140860-02 122212-40 127724-02 141514-02 143615-02
119059-56 122261-03 136998-09 141518-12 143731-01
119213-23 122675-05 137000-07 141552-03 143733-01
124628-10 123003-04 137080-05 141558-01 143977-01
119252-29 123590-12 137147-06 141586-01 144053-04
119280-23 123893-22 138195-04 141590-02 144106-01
124188-03 124393-11 138822-07 141874-09 144254-01
120199-15 124457-02 138826-07 141876-07 144488-04
119534-19 124630-42 138880-02 142084-04 144492-01
120272-28 125215-03 139099-04 142397-01 145124-01
119757-18 125388-03 139620-01 142529-01 145796-01
119783-15 125555-07
Following patches were skipped :
Patches already applied
120900-04 119063-01 119810-05 123005-07 137093-01
121133-02 119081-25 119986-03 124444-01 138866-03
119317-01 119130-33 120061-02 124939-03 137137-09
121296-01 123611-04 120201-05 124943-01 137871-02
138215-01 140899-01 120292-02 124997-01 138181-01
127884-01 122640-05 120329-02 125279-05 138361-01
118712-23 126897-02 121975-01 125539-06 138373-02
118918-24 127755-01 120719-02 125891-01 138647-01
138217-01 125503-02 120830-06 126440-01 141016-01
119578-30 125547-02 121095-02 126540-02 139555-08
121453-02 140796-01 121606-04 127127-11 139967-01
121453-02 120011-14 124171-07 136882-02 140455-01
121118-16 139520-02 123630-03 137032-01 140563-01
118833-36 119764-06
Patches obsoleted by one or more patches already applied
118731-01 124204-04 122660-10
Patches not applicable to packages on the system
121181-03 120410-33 121211-02 125533-15 143317-03
119115-35 120412-11 122259-03 125541-06 143510-01
119117-52 120414-27 122470-03 125952-20 143725-01
119315-19 120543-21 122911-24 137004-08 143727-01
119548-14 120739-06 122958-06 138387-01 143739-01
119903-02 120811-09 123938-02 138824-07 144325-01
120094-30 120849-04 125136-24 138876-01 145006-02
120185-21 121104-11 125137-24 139986-01 145080-01
119368-04 121136-02 125332-14 142244-02 145200-01
120286-03
Installation of patch set complete. PLEASE REBOOT THE SYSTEM.
when i tried to reboot the system by init 6 the service iscsi hanged and produced syslog errors about a unkown iocall -> killed the process. System rebooted w/o errors.
Does anyone have got an idea how to find out which patch or whatever do produce these errors?

Hi,
I'm having the same issue of diskmon core dumps after upgrading grid and database from 11.2.0.1 to 11.2.0.2 on Solaris 10 x86-64. Following this thread, I'm trying to deinstall the Oracle 11.2.0.1 grid home.
I answered the following questions asked by the grid deinstall tool:
1. ASM configuration was not detected in this Oracle home. Was ASM configured in this Oracle home (y|n): y
2. Specify the ASM Diagnostic Destination: /db01/app/oracle/diag/asm/+ASM
3. Specify the diskgroups that are managed by this ASM instance: DATA FRA
4. De-configuring ASM will drop all the diskgroups at cleanup time. Do you want deconfig tool to drop the diskgroups:
If I answer no to question 1, the tool exits with error.
How do I answer question #4? (confused about this question of dropping diskgroups, it's already been upgraded)
Deinstall of Oracle db Home 11.2.0.1 was successful.
The +ASM instance has been upgraded and is running fine under 11.2.0.2 except for the excessive diskmon core dumps.
Thanks,
Lisa
Edited by: user12018917 on Apr 19, 2011 10:21 AM

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

Core dump on Solaris 8 Patch-15

I have compiled my code on Solaris 8 machine with the Kernal Custer Paths 12 and is working properly on the same machine. IF I move to a similar Solaris 8 machine with Patch 15 it core dumps. Do I have to recompile on Patch 15 environment? Or is it some other problem. The core happens when the executable is using C libraries (libc.so.1)

The program probably dumped core with seg fault? The
libc might well have changed with a kernel patch. I
would recommend that you recompile. If the failure
persists, I would post your question on the Solaris
forum as the lib with "little c" is maintained in the
OS and not in the Compiler Collection.

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]

JVM core dump on Solaris

Hi,
I am using JDK 1.4.1_07 to run an application on Tomcat 4.1.27 on Solaris 5.8. I get a core dump on a load test. catalina.out has this line:
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
# Java VM: Java HotSpot(TM) Server VM (1.4.1_07-b02 mixed mode)
# Error ID: 434934595045264C4F570E43505009D0 01
# Problematic Thread: prio=5 tid=0x10be48 nid=0xf runnable
The page http://java.sun.com/cgi-bin/bugreport.cgi is not available. Where can I file a bug report? Any ideas on the crash?
Thanks,
Chandri

I do not have problem changing the jdk version, but my application runs slow on jdk1.4.2, till i figure out why it slow i want continue using jdk1.4.1.
Is this a know issues in Jdk1.4.1, I see a bug (Bug Id: 4908923) on core dump, is this related?
http://developer.java.sun.com/developer/bugParade/bugs/4908923.html
See the both note, fix to this bug is not included in jdk1.4.1_07.
Any idea?

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

Dynamic binary core dumped on solaris 10 x86 platform !!!!

Hi,
I have problem with dynamic binary compiled on solaris 10 x86 with sun studio 10, when i tryed to start this binary i have "illegal instruction (core dumped)".
But when i generate a static binary, there is NO PROBLEM! the binary start normally!
also when i compiled the binary, there is no problem, the compilation is normally terminated in both case (static and dynamic)!
I would be most grateful for any response.
Best Regards,
Skander

Hi,
Yes - that's a little confusing; Oracle Collaboration Suite 10g is certified on a 64b Solaris SPARC. (The story behind the 32b is a long one, but it's related to client libraries vs. database servers and how 32b/64b liibraries are distinguished).
To answer your real question, though, No - it's not supported on Solaris x86.
richard

JVM core dumps on Solaris

Need help asap on know where/why my JVM core dumped. I've the logs from the process but they dont seen to indicate any odd thing. I've tried to debug the core using dbx like :
dbx /usr/bin/java ./core
but keep getting message: dbx: program is not activePls advise ASAP.
Can anyone also point how to contact Sun for this like sending them the core over etc.

This document may help: http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf
To contact Sun, click the Contact Us link at the bottom of the page. All of their services have charges associated.

Core dump with deque program

Hey all, here is the small deque program...
When this program was run for upto 529 entires it works fine. When tried for 530 entries it dumps core.
By the way instead of push_front if we use push_back, it works fine. However, we are facing this problem with Sun ONE Studio 11 after our successful compiler upgrade.
If any one has any idea why the following program dumping core with 530 entires?
cut and paste and compile and run ./deque 530, you will receive a core dump in Solaris 10/Sun one Studio 11 (CC 5.8 compiler). Important: make sure you run Solaris 10/Sun One Studio 11 CC 5.8 compiler compiled code.
IT IS NOT DUMPING CORE IN OLDER VERSIONS....
==========deque.cc===================
#include <deque>
#include <iostream>
int main( int argc, char* argv[] )
std::deque< int > container;
std::cout << "maxSize:" << container.max_size() << "\n";
int last( 530 );
if ( argc > 1 )
last = atoi( argv[ argc - 1 ] );
std::cout << "Building to " << last << "\n";
for ( int i = 0; i < last; ++ i )
container.push_front( i );
int idx = 0;
for ( std::deque< int >::const_iterator
iter = container.begin();
iter != container.end();
++ iter, ++ idx )
std::cout << idx << ": " << (*iter) << "\n";
std::cout << "maxSize:" << container.max_size() << "\n";
return 0;
The pstack output from core file...
core 'core.deque' of 3869: ./deque 530
00011a40 main (2, ffbfd7ec, ffbfd758, ffbfd768, ffbfd768, ffbfd630) + 2b8
00011358 _start (0, 0, 0, 0, 0, 0) + 108

The patch that fixes CR 6363210 involves the header files for the deque implementation in Sun Studio 10 and 11. The runtime library /usr/lib/libCstd.so.1 also has that code in it. Whether you generate the affected functions inline in your code, or pick them up from the runtime library, depends on various compiler options.
If you have not installed the latest C++ runtime library patch and get these functions from the runtime library, you will not have the benefit of the bug fix.
You can get all current patches here:
http://developers.sun.com/sunstudio/downloads/patches/index.jsp
If after installing current patches you still have the problem, please post a stand-alone code example that shows the problem.

How to collect core dump file

Hello all,
how to collect core dump on Solaris 10.
Thanks alot

Moderator advice: Don't double post. The other thread you started in the Servers General Discussion forum with the identically same question has been removed.
The only response on that thread is reproduced below.
db
ReneF wrote:
Hi Vutha,
Are you looking for instructions on collecting a core file, created by a failing userland process, or do you want to collect kernel crashdump files ?
You can look at the output of the coreadm command to find out what file is stored in which location.
What to collect is nicely described in [url https://supporthtml.oracle.com/ep/faces/secure/km/DocumentDisplay.jspx?id=1010911.1]What to send to Oracle Sun after a system panic and/or unexpected reboot (Doc ID 1010911.1).
Did you know we have two community categories in My Oracle Support, where you also can post your questions ? Have a look at [url https://communities.oracle.com/portal/server.pt/community/sun_sparc_enterprise_servers/447]Sun SPARC Enterprise Servers and [url https://communities.oracle.com/portal/server.pt/community/oracle_sun_technologies/388] Oracle Sun Technologies .
Hope this helps,
Kind regards,
Rene

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.

Similar Messages

Maybe you are looking for