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
Similar Messages
-
Solaris 9 x86 platform update 4 8/03 can not start Management Console
smc& but cannot start management console 2.1
no problem on solaris 8 x86 platform.
Error as below :
I cannot start the Solaris Management Console in Solaris 9. The splash screen appears for a few seconds, then nothing else, core dumped.
There is a error: "Assertion Fail: Offset < fFileSize ............../../../src....
Any ideas ??????Java Bug 4838130:
http://developer.java.sun.com/developer/bugParade/bugs/4838130.html
suggests to trace the problem by running the java application with JAVA2D_DEBUGFONTS defined, so try
env JAVA2D_DEBUGFONTS=1 smc
The bug report also documents a workaround: Set the environment variable JAVA_FONTS to
/usr/openwin/lib/X11/fonts/TrueType, i.e.
env JAVA_FONTS=/usr/openwin/lib/X11/fonts/TrueType smc -
OCS 10.1.2 on Solaris 10 x86 Platform
Can any one tell me whether OCS 10.1.2 supports Solaris 10 x86 Platform?
On the download page it says;
Oracle Collaboration Suite 10g Release 1 (10.1.2) for Solaris Operating System (SPARC 32-bit)
But we all know SPARC is 64-bit. Can someone clarify this.
Thanks!
RavinHi,
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 -
Statically linking libstdc++ on Solaris 10 x86 platform
hi,
Using g++, how do i statically link libstdc++ on Solaris 10 x86 platform?
What are the necessary linker options?
-Thanks and Regards,
AmeyaQuestions about using g++ are more likely to get a helpful answer in a g++ forum.
Try http://gcc.gnu.org/ -
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). -
Compiled binary crashes during initialization on Solaris 10/x86 platform
Hi, I have a problem to run application built with Solaris Sun Studio compiler. It dumps a core which contains:
$c_init+0x19a(1, 804761c, 8047624, 8047610, 80dabfd, 80da64c)
_start+0x78(1, 8047744, 0, 804774c, 8047756, 8047829)
>
When application is run under "dbx" utility the output looks:
Reading ld.so.1
Reading libTAO_CosNaming.so.1.4.0
Reading libTAO_Svc_Utils.so.1.4.0
Reading libTAO_IORTable.so.1.4.0
Reading libTAO_PortableServer.so.1.4.0
Reading libTAO.so.1.4.0
Reading libACE.so.5.4.0
Reading libxerces-c.so.28.0
Reading libicuuc.so.3
Reading libfbclient.so.2.1.1
Reading libdl.so.1
Reading libpthread.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libxnet.so.1
Reading librt.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.2
Reading libthread.so.1
Reading libc.so.1
Reading libTAO_Messaging.so.1.4.0
Reading libgen.so.1
Reading libTAO_ObjRefTemplate.so.1.4.0
Reading libTAO_Valuetype.so.1.4.0
Reading libTAO_IORInterceptor.so.1.4.0
Reading libicudata.so.3
Reading libcurses.so.1
Reading libaio.so.1
Reading libmd.so.1
(dbx) run
Running: app
(process id 13240)
t@1 (l@1) signal SEGV (no mapping at the fault address) in __cplus_fini_at_exit at 0x8393ba5
0x08393ba5: __cplus_fini_at_exit+0x01c9: addb %al,(%eax)
(dbx) where
current thread: t@1
=>[1] __cplus_fini_at_exit(0x8047664, 0x8047770, 0x804769c, 0x81ca778, 0x1, 0x80476a8), at 0x8393ba5
As you can see the application uses some 3rd party libraries, like: ACE (v5.4.0)/TAO (v1.4.0), xerces (v2.8), ICU (v1.2) and Firebird2 (v2.1.1) libraries. The libs were compiled using the same compiler. The problem seems to be within runtime linker - the core was dumped before the code started execution.
I have reproduced the issue with two different versions of compiler:
1. Older
/usr/bin/CC -V
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25
uname -a
SunOS XXX 5.10 Generic_139556-08 i86pc i386 i86pc
2. Newer
/usr/bin/CC -V
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-17 2009/10/27
uname -a
SunOS YYY 5.10 Generic_141415-04 i86pc i386 i86pc
Interesting observation, suggesting there is some problem with either linker or runtime linker:
I have a version of the application which runs properly but when I add just one line - include of one of ACE headers to the class which did not contain ACE I end up with the problem described above but if I add any number of includes of ACE headers to the class which already contained (directly or indirectly) ACE code the application still works.
The same source code is compiled on Solaris 9/SPARC platform and it works:
CC -V
CC: Sun C++ 5.5 Patch 113817-19 2006/10/13
uname -a
SunOS ZZZ 5.9 Generic_118558-35 sun4u sparc SUNW,Sun-Fire-V240
Is it any known issue? Thanks in advance for any input.Hi
Thanks for the answer. I have analyzed my code and found out that, indeed, some static singleton objects were incorrectly implemented. It has been fixed and the application started when compiled under C++ 5.9, but it does not seem to solve the problem. The application was recompiled using the the newest Sun Studio 12.1 9 (C++ 5.10), and then failed to start again. As per your suggestion regarding the place in the code where the crash occurs, I have compared "__cplus_fini_at_exit" functions for both working and broken applications, compiled under C++ 5.9. Here are parts of code (actually, few last lines of the function) from:
- working
0x0827b811: __cplus_fini_at_exit+0x01b5: call __STATIC_CONSTRUCTOR [ 0x81c9dec, .-0xb1a25 ]
0x0827b816: __cplus_fini_at_exit+0x01ba: call __STATIC_CONSTRUCTOR [ 0x81cfb18, .-0xabcfe ]
0x0827b81b: __cplus_fini_at_exit+0x01bf: call __STATIC_CONSTRUCTOR [ 0x81d1004, .-0xaa817 ]
0x0827b820: __cplus_fini_at_exit+0x01c4: call OPENSSL_cpuid_setup [ 0x81e88a0, .-0x92f80 ]
0x0827b825: __cplus_fini_at_exit+0x01c9: jmp __cplus_fini_at_exit+0x1d4 [ 0x827b830, .+0xb ]
0x0827b827: __cplus_fini_at_exit+0x01cb: movl %esi,%esi
0x0827b829: __cplus_fini_at_exit+0x01cd: leal 0x00000000(%edi),%edi
0x0827b830: __cplus_fini_at_exit+0x01d4: nop
0x0827b831: __cplus_fini_at_exit+0x01d5: popl %ebx
0x0827b832: __cplus_fini_at_exit+0x01d6: popl %esi
0x0827b833: __cplus_fini_at_exit+0x01d7: popl %edi
0x0827b834: __cplus_fini_at_exit+0x01d8: leave
0x0827b835: __cplus_fini_at_exit+0x01d9: ret $0x00000000- broken
0x0827b307: __cplus_fini_at_exit+0x01ab: call __STATIC_CONSTRUCTOR [ 0x81c86e8, .-0xb2c1f ]
0x0827b30c: __cplus_fini_at_exit+0x01b0: call __STATIC_CONSTRUCTOR [ 0x81c8eb4, .-0xb2458 ]
0x0827b311: __cplus_fini_at_exit+0x01b5: call __STATIC_CONSTRUCTOR [ 0x81c9b2c, .-0xb17e5 ]
0x0827b316: __cplus_fini_at_exit+0x01ba: addb %al,(%eax) <=====
0x0827b318: __cplus_fini_at_exit+0x01bc: addb %al,(%eax)
0x0827b31a: __cplus_fini_at_exit+0x01be: addb %al,(%eax)
0x0827b31c: __cplus_fini_at_exit+0x01c0: addb %al,(%eax)
0x0827b31e: __cplus_fini_at_exit+0x01c2: addb %al,(%eax)
0x0827b320: __cplus_fini_at_exit+0x01c4: call OPENSSL_cpuid_setup [ 0x81e83a0, .-0x92f80 ]
0x0827b325: __cplus_fini_at_exit+0x01c9: jmp __cplus_fini_at_exit+0x1d4 [ 0x827b330, .+0xb ]
0x0827b327: __cplus_fini_at_exit+0x01cb: movl %esi,%esi
0x0827b329: __cplus_fini_at_exit+0x01cd: leal 0x00000000(%edi),%edi
0x0827b330: __cplus_fini_at_exit+0x01d4: nop
0x0827b331: __cplus_fini_at_exit+0x01d5: popl %ebx
0x0827b332: __cplus_fini_at_exit+0x01d6: popl %esi
0x0827b333: __cplus_fini_at_exit+0x01d7: popl %edi
0x0827b334: __cplus_fini_at_exit+0x01d8: leave
0x0827b335: __cplus_fini_at_exit+0x01d9: ret $0x00000000In the broken version, the crash occurs when executing addb %al,(%eax) instruction at 0x0827b316 (marked above with an arrow). This is because %eax points to some read-only memory - the implementation of one of classes method in this case.
As you can see, in this address there are 5 2-byte long instructions addb %al,(%eax). Their location in this place seems to make no sense from function logic point of view:
1. Why would we need to add %al register contents five times in a row, to the memory pointed by %eax, in this place?
2. The __cplus_fini_at_exit() function in the working application, that basically looks identical, does not have this sequence of instructions at all.
Looking at the memory dump in this place shows that these are physically 10 bytes of zeros ("e8 f4 ff 00 00 00 00 00 00 00 00 00 00 e8 7b d0") at 0x0827b316 (indeed, the instruction addb %al,(%eax) is binary coded as 0x00 0x00). It seems, that for some reason, the block of 10 bytes with zero value was injected to the compiler generated code.
I would like to stress - this is not a result of program initialization as both listings presented above come from the applications loaded to "dbx" but not started so they only reflect how binaries look like. I have made one more test - I have edited broken binary and replaced these 10 bytes of zeros with ten "No Operation" instructions ("e8 f4 ff 90 90 90 90 90 90 90 90 90 90 e8 7b d0"). Here is output from "dbx", after the changes made:
0x0827b307: __cplus_fini_at_exit+0x01ab: call __STATIC_CONSTRUCTOR [ 0x81c86e8, .-0xb2c1f ]
0x0827b30c: __cplus_fini_at_exit+0x01b0: call __STATIC_CONSTRUCTOR [ 0x81c8eb4, .-0xb2458 ]
0x0827b311: __cplus_fini_at_exit+0x01b5: call __STATIC_CONSTRUCTOR [ 0x81c9b2c, .-0xb17e5 ]
0x0827b316: __cplus_fini_at_exit+0x01ba: nop
0x0827b317: __cplus_fini_at_exit+0x01bb: nop
0x0827b318: __cplus_fini_at_exit+0x01bc: nop
0x0827b319: __cplus_fini_at_exit+0x01bd: nop
0x0827b31a: __cplus_fini_at_exit+0x01be: nop
0x0827b31b: __cplus_fini_at_exit+0x01bf: nop
0x0827b31c: __cplus_fini_at_exit+0x01c0: nop
0x0827b31d: __cplus_fini_at_exit+0x01c1: nop
0x0827b31e: __cplus_fini_at_exit+0x01c2: nop
0x0827b31f: __cplus_fini_at_exit+0x01c3: nop
0x0827b320: __cplus_fini_at_exit+0x01c4: call OPENSSL_cpuid_setup [ 0x81e83a0, .-0x92f80 ]
0x0827b325: __cplus_fini_at_exit+0x01c9: jmp __cplus_fini_at_exit+0x1d4 [ 0x827b330, .+0xb ]
0x0827b327: __cplus_fini_at_exit+0x01cb: movl %esi,%esi
0x0827b329: __cplus_fini_at_exit+0x01cd: leal 0x00000000(%edi),%edi
0x0827b330: __cplus_fini_at_exit+0x01d4: nop
0x0827b331: __cplus_fini_at_exit+0x01d5: popl %ebx
0x0827b332: __cplus_fini_at_exit+0x01d6: popl %esi
0x0827b333: __cplus_fini_at_exit+0x01d7: popl %edi
0x0827b334: __cplus_fini_at_exit+0x01d8: leave
0x0827b335: __cplus_fini_at_exit+0x01d9: ret $0x00000000This time the application has started. As everything occurs inside compiler-generated function it seems to me that this analysis strongly suggests that there is a problem with a compiler which puts 10 bytes of mess into __cplus_fini_at_exit.
The binaries used above were built using:
/usr/bin/CC -V
CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25
I have also checked Sun Studio 12.1 (C++ 5.10) compiler but the attempts to get working application failed (the same problem with zero bytes).
Have you ever encountered similar problem? Are you able to confirm/deny whether it is related to the compiler?
Thanks for further assistance -
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 -
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) -
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]
-
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,
ChandriI 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? -
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
-
USB port 1 & 3 not working, BT not available
iMAC 27", Mid 2011 The USB port 1 & 3 (1 is near the firewire port) are not working, also Bluetooth is not available. I try to reset PRAM and SMC but it didnt change the situation. When executing Hardware Test (Diagnostics) no errors are found (short
-
A friend gave it to me to see if I could get it up and running again. It has no HDD or RAM (in addition to the native 64MB), nor does it have any of the optical drives, and I'm nearly certain the battery is dead. I found the power cord and plugged
-
The listener supports no services
Hello, I have trouble to connect to DB after unxpected reboot due power outage ... Listener is not running. After start of Listener is not possible to connect to DB still. Here is the state of Listener: lsnrctl stat LSNRCTL for Linux: Version 11.2.0.
-
Can't open iDVD v7 from iLife 08 on Lion? Please help
I just got a new iMac pre loaded with Lion. I had iLife 08 on my old 2008 MacBook Pro. I did a custom install with the iLife disk and only installed iDVD. It placed it in the application folder but when i try to open it i get an error message sayi
-
My Mac book air cord will not charge
My MacBook air cord will not charge.