Core file in solaris

Hi all I am on solaris sparac 10 ...I have some core files generated .. I ran pstack on it and it shows some info but not exact ..
also how I can decode xxxfff01001001010 such messages in there ..
any other utility that can give more details info on core.
thanks

The only couple of things you can do are:
run the command: # file <COREFILE> and this will tell you the name of the binary which provoked the core
run the command: # pstack <COREFILE> which on the very first line will tell you the command line that was executed
Other than that, either you're a developer with access to the source code, or there's not much you can do.
HTH,
marco
P.S.: Please mark this response as correct or helpful when appropriate to make it easier for others to find it

Similar Messages

Maximum Core File Size for Solaris 8

I believe that RLM_INFINITY for Solaris for core file sizes comes to 2GB.
Is there any mechanism ( patch ) etc. by which this can be increasd ?

if your application is 32-bit, then the core file size would be limited to 4GB (by default) and if your application is
64-bit, then the core file size would be limited to usigned long max (by default).
-Saurabh

Application running in Solaris 9 container generating core files. what to do?

My solaris 9 zone configuration in solaris 10 looks like:
zonecfg:sms> info
zonename: sms
zonepath: /zone/sms
brand: solaris9
autoboot: true
bootargs:
pool:
limitpriv: default,proc_priocntl,proc_clock_highres,proc_lock_memory,sys_time,priv_proc_priocntl,priv_sys_time,net_rawaccess,sys_ipc_config,priv_proc_lock_memory
scheduling-class:
ip-type: exclusive
hostid:
[max-shm-memory: 4G]
[max-shm-ids: 100]
[max-sem-ids: 100]
fs:
dir: /var
special: /dev/dsk/c1t0d0s5
raw: /dev/rdsk/c1t0d0s5
type: ufs
options: []
net:
address not specified
physical: bge0
defrouter not specified
device
match: /dev/dsk/c1t0d0s5
device
match: /dev/rdsk/c1t0d0s5
device
match: /dev/dsk/c1t0d0s6
device
match: /dev/rdsk/c1t0d0s6
device
match: /dev/dsk/c1t0d0s7
device
match: /dev/rdsk/c1t0d0s7
capped-cpu:
[ncpus: 2.00]
capped-memory:
physical: 4G
[swap: 8G]
[locked: 2G]
attr:
name: hostid
type: string
value: 84b18f64
attr:
name: machine
type: string
value: sun4u
rctl:
name: zone.max-sem-ids
value: (priv=privileged,limit=100,action=deny)
rctl:
name: zone.max-shm-ids
value: (priv=privileged,limit=100,action=deny)
rctl:
name: zone.max-shm-memory
value: (priv=privileged,limit=4294967296,action=deny)
rctl:
name: zone.max-swap
value: (priv=privileged,limit=8589934592,action=deny)
rctl:
name: zone.max-locked-memory
value: (priv=privileged,limit=2147483648,action=deny)
rctl:
name: zone.cpu-cap
value: (priv=privileged,limit=200,action=deny)
Solaris 9 zone /etc/system file looks like:
* The directive below is not applicable in the virtualized environment.
* The directive below is not applicable in the virtualized environment.
* The directive below is not applicable in the virtualized environment.
* The directive below is not applicable in the virtualized environment.
* The directive below is not applicable in the virtualized environment.
* The directive below is not applicable in the virtualized environment.
set noexec_user_stack=1
set semsys:seminfo_semmni=100
set semsys:seminfo_semmns=1024
set semsys:seminfo_semmsl=256
set semsys:seminfo_semvmx=32767
set shmsys:shminfo_shmmax=4294967295
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=100
set shmsys:shminfo_shmseg=10
set rlim_fd_max=65536
set rlim_fd_cur=60000
* The directive below is not applicable in the virtualized environment.
My questions are:
1. Application running in solaris 9 container generating core files. what to do???
2. My prstat -Z for zone shows almost 95% percent cpu usage. what to do???
3. Kindly can share how to move solaris 9 into solaris 10 containers ??

Based on the new questions for the same post you wrote in the other communities, some posts are removed as duplicate, here is the answer :
For the point #3, please look on table 17-1 in the following URL :
Zone Components - System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones
You can also customize your container /etc/system file but it cannot exceeds the global zone and the zone configuration value.
For the other point, #2, this can be complicated without a complete image of what the complete system do.
Try fist to check if you have not a busy process in your zone, then you can check if a bottleneck exists in the I/O side. You use maybe wrong parameters, a wrong configuration or your system configuration is insufficient in term of resources.
What I can see in the outputs that you provided is that the S9 zone uses the half of the swap space. This can impact your zone performance and I/O activity, and can have in this case a side effect on some processes. Check why your zone uses the swap and how you can remedy this.

Solaris 10 update 6 keeps generating core file (/core)

I wonder if somebody has encountered the following issue.
I did a fresh install of Solaris 10 update 6 on two servers (T5140 and T524) from DVD.
I noticed that a core file was in the root filesystem (/core).
So, I deleted it.
As soon as I delete the core file, another one is generated.
This is happening on both servers where I installed Solaris 10 update 6 from the DVD.
This is not a live update install. Solaris was installed from scratch. When prompted to preserve previous data, I replied with 'do not preserve data'
Does anybody know where the core file is coming from and how to stop it being generated?
Found out that is coming from vold
SunOS b1osdtsun02 5.10 Generic_137137-09 sun4v sparc SUNW,T5240
# more /etc/release
                      Solaris 10 10/08 s10s_u6wos_07b SPARC
           Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
                        Use is subject to license terms.
                            Assembled 27 October 2008
# mdb /core
Loading modules: [ libsysevent.so.1 libnvpair.so.1 libc.so.1 ld.so.1 ]
::statusdebugging core file of vold (32-bit) from b1osdtsun02
file: /usr/sbin/vold
initial argv: /usr/sbin/vold -f /etc/vold.conf
threading model: multi-threaded
status: process terminated by SIGSEGV (Segmentation Fault)
::stacklibc.so.1`strlen+0x18(408450a5, 0, 0, 88b70, 600, 180)
read_slices+0x114(874a0, b, 889a0, feeafd34, 1, 5)
read_hsfs_partition+0x88(b, 46c00, 6d0000, 2c, 34400, 1010101)
read_partition+0x30(874a0, 341a4, 3, 34000, 34400, 9)
create_top_partition+0x140(7cbe0, 7cc24, 7cbe0, 874a0, ffffffff, b)
0x265e0(800012, feeaff9c, c, 598e0, 7cbe0, ffffffff)
create_medium+0x74(800012, feeaff9c, 20, 12, 47800, c)
0x2232c(5d278, 0, 0, 800012, 20, 33000)
libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0)
>
#It seems that vold is failing to mount the DVD on both servers after Solaris was installed.
Is this a Solaris 10 update 6 bug?
Edited by: shen on Jan 29, 2009 8:45 PM

Never mind.
It is a known bug documented on manual " [Solaris 10 10/08 Release Notes, Chapter 2 Solaris Runtime Issues|http://docs.sun.com/app/docs/doc/820-5245/chapter2-1000?a=view] " as shown below.
The solution is to apply vold patch [138130-01|http://sunsolve.sun.com/search/document.do?assetkey=1-21-138130-01-1].
Solaris 10 10/08 DVD Media Might Not be Automatically Mounted by vold (6712352)
The Solaris 10 10/08 DVD does not mount by default during runtime. No error message is displayed.
Workaround: Perform the following steps:
   1. Become superuser.
   2. Disable vold:
      * On Solaris 10 Systems:
            # svcadm disable -t volfs
      * On Solaris 8 and Solaris 9 systems:
            /etc/init.d/volmgt stop
   3. Mount the media manually by using the # mount -F hsfs path to block device path to mount point command. For example:
      # mount -F hsfs /dev/rdsk/c0t2d0s2 /mnt

Possible to get data from a partly optimized/stripped core file?

Hello,
This may not be possible, but I figured it was worth asking about.
I've got a C/C++ GUI application compiled with Solaris Studio 12.3 that is experiencing an infrequent crash when compiled for production and running on production boxes. This is on Solaris 10 for x86 running in 64-bit mode. Most of the app is in libraries which are statically linked.
I working on trying to replicate the issue in a development environment, but have not had luck yet. In any case, it would be interesting to know what kind of data can be gleaned postmortem from the core file I've got access to.
The application is actually a small "main.c" file which is complied and linked in debug mode with "-g" and no optimization, but this thin wrapper calls into the main logic in statically linked libraries which are optimized and not built in debug mode. (See the call stack below.)
From the core file :
1) For functions in the call stack that have names, can I get the value of one of the parameters? I ask because several such functions take pointers to structs with data that should be very useful.
2) For functions in the call stack that appear as ??????, is it possible to determine at least what .o or .a file they came from? This could help narrow things down.
Some basic Googling indicates that either of the above may not be trivial or even possible. But I'm wondering if the fact that we've got a "main.c" debuggable wrapper might somehow help.
As a related question, pstack produces sensible output, but dbx shows the error: "dbx: internal error: could not iterate over load objects -- link-maps are not initialized". Is there some flag I need to supply to dbx?
Thank you for any help,
David
Background info:
I've been unable to replicate on non-production deployments, but the machines do differ a bit.   Eventually I will be able to borrow a production box to deploy an instrumented binary, but for now all I've got is a core file and access to source.
The core was generated with gcore while the app was displaying a popup from it's SIGABRT cleanup handler.   The production build scripts do some binary stripping, but I'm not yet sure where it is getting done.
Here is the (slightly cleaned up) output of pstack for the core file:
fffffd7ffeb3244a nanosleep (fffffd7fffdfd4b0, 0)
0000000000514485 ZWidget_ModalEventLoop () + 65
00000000004f74a9 ZWidget_ShowPopup () + 4a9
000000000049d2ab ???????? ()
fffffd7ffeb2dd16 __sighndlr () + 6
fffffd7ffeb225e2 call_user_handler () + 252
fffffd7ffeb2280e sigacthandler (6, 0, fffffd7fffdfd640) + ee
--- called from signal handler with signal 6 (SIGABRT) ---
fffffd7ffeb3351a _lwp_kill () + a
fffffd7ffead81b9 raise () + 19
fffffd7ffeab6b4e abort () + 5e
000000000052c3bc ZUtil_Query () + 3c
000000000059b66e ZUtil_QueryString () + 3e
00000000004a1e2a ???????? ()
00000000004a0879 ???????? ()
000000000058b303 ???????? ()
000000000052d517 ZUtil_Set () + 767
00000000004f4805 ZUtil_DBSet () + 35
00000000005094b5 ZWidget_ProcessCallback () + 465
0000000000516814 ???????? ()
fffffd7fff242424 XtCallCallbackList () + 114
fffffd7ffef84d2e ActivateCommon () + 126
fffffd7ffef84b72 Activate () + 1e
fffffd7fff244efa HandleActions () + 14a
fffffd7fff24b1b7 HandleComplexState () + 177
fffffd7fff243a9e _XtTranslateEvent () + 4e
fffffd7fff24382a XtDispatchEventToWidget () + 2ea
fffffd7fff2430ee _XtDefaultDispatcher () + 15e
fffffd7fff242db6 XtDispatchEvent () + 106
00000000005142df ZWidget_ProcessEvent () + ff
0000000000514099 ZWidget_ProcessEvents () + 19
00000000005ac67a ZEventLoop_ProcessEvents () + 5a
00000000005ac528 ZEventLoop_Execute () + 48
000000000049d133 Main () + c93
000000000049bdf9 main () + 9
000000000049bc7b ???????? ()

Thanks for reporting this problem.
>1) For functions in the call stack that have names, can I get the value of one of the parameters? I ask because several such functions take pointers to structs with data that should be very useful.
Use compiler option -preserve_argvalues={none|simple|complete} to preserve incoming argument values. Note that this feature was introduced in Oracle Solaris Studio 12.4.
You may also be interested in a new option in Oracle Solaris Studio 12.4 which provides much finer-grained control over debug information, which allows you to choose how much information is provided and to reduce the amount of disk space needed for the executable. Dev Tip: How to Get Finer-Grained Control of Debugging Information.
>2) For functions in the call stack that appear as ??????, is it possible to determine at least what .o or .a file they came from? This could help narrow things down.
The following 2 commands may help:
where -l
# Include library name with function name.
whereis -a <addr-of-?????> # Print location of an address expression
>As a related question, pstack produces sensible output, but dbx shows the error: "dbx: internal error: could not iterate over load objects -- link-maps are not initialized". Is there some flag I need to supply to dbx?
This may be caused by corefile mismatch. See dbx online help: "help core mismatch" for suggestions.
Hope this helps.

Core file creation in weblogic 10.3 with 1.6.0_24 ( Urgent )

Hi ALL ,
Recently we have migrated the java version from 1.6.0_16 to 1.6.0_24 in production environment . We are using weblogic 10.3 .
Once from the migration the managed servers is going to unknown state at sometime which is configured as cluster configuration .
We have two managed servers with cluster configration .
When the servers is going to unknown state the core file is geting created .
This is urgent can any body help on this ( prior thanks ) - why we are getting this and what is the sloution ?
Attached the core file conntent from one managed servers
Managed 1 server log name : hs_err_pid17198.log
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0xa7bd8404, pid=17198, tid=2453
JRE version: 6.0_24-b07
Java VM: Java HotSpot(TM) Server VM (19.1-b02 mixed mode solaris-sparc )
Problematic frame:
C [pkcs11_softtoken.so.1+0x38404]
If you would like to submit a bug report, please visit:
http://java.sun.com/webapps/bugreport/crash.jsp
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.
--------------- T H R E A D ---------------
Current thread (0x024e6800): JavaThread "Thread-1144" daemon [_thread_in_native, id=2453, stack(0xa0800000,0xa0880000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00000100
Registers:
O0=0xff000000 O1=0x00ffffff O2=0xff000000 O3=0x03364348
O4=0xfc0059d0 O5=0x00fffc00 O6=0xa087cbc0 O7=0xff2bee44
G1=0x00000004 G2=0x00000d00 G3=0x00000001 G4=0x00001ffc
G5=0xfee3cf6c G6=0x00000000 G7=0xa6f40a00 Y=0x00000000
PC=0xa7bd8404 nPC=0xa7bd8408
Register to memory mapping:
O0=0xff000000
0xff000000: __libm__rem_pio2m+0xfe0 in /lib/libm.so.2 at 0xfef80000
O1=0x00ffffff
0x00ffffff is pointing to unknown location
O2=0xff000000
0xff000000: __libm__rem_pio2m+0xfe0 in /lib/libm.so.2 at 0xfef80000
O3=0x03364348
0x03364348 is pointing to unknown location
O4=0xfc0059d0
return entry points [0xfc0050c0, 0xfc0067e0] 5920 bytes
O5=0x00fffc00
0x00fffc00 is pointing to unknown location
O6=0xa087cbc0
0xa087cbc0 is pointing into the stack for thread: 0x024e6800
"Thread-1144" daemon prio=3 tid=0x024e6800 nid=0x995 runnable [0xa087e000]
java.lang.Thread.State: RUNNABLE
O7=0xff2bee44
0xff2bee44: thrschedctl+0xbf0 in /lib/libc.so.1 at 0xff200000
G1=0x00000004
0x00000004 is pointing to unknown location
G2=0x00000d00
0x00000d00 is pointing to unknown location
G3=0x00000001
0x00000001 is pointing to unknown location
G4=0x00001ffc
0x00001ffc is pointing to unknown location
G5=0xfee3cf6c
0xfee3cf6c: __1cHnmethodG__vtbl_+0xcc4 in /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/server/libjvm.so at 0xfe400000
G6=0x00000000
0x00000000 is pointing to unknown location
G7=0xa6f40a00
0xa6f40a00 is pointing to unknown location
Top of Stack: (sp=0xa087cbc0)
0xa087cbc0: 00000000 ed6a8fac ed6a8fb8 a087f0dc
0xa087cbd0: ff3454c4 00000000 01000000 00001cc4
0xa087cbe0: 00000000 00000012 a087dd50 00000012
0xa087cbf0: a087cd4c a087dd50 a087cc20 a7bbf0b4
0xa087cc00: a087fa70 024e540c 024e5414 024e5404
0xa087cc10: 005572b9 a9fac000 00000000 fe53ec98
0xa087cc20: 00000000 ecf00002 fffff841 00000111
0xa087cc30: 00000001 fffff8c9 01000000 fffffff0
Instructions: (pc=0xa7bd8404)
0xa7bd83f4: 82 0f 20 07 80 90 60 00 02 80 00 20 b4 10 00 1d
0xa7bd8404: e6 0e 21 00 80 a6 60 00 e4 0e 21 01 08 80 00 17
Stack: [0xa0800000,0xa0880000], sp=0xa087cbc0, free space=498k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [pkcs11_softtoken.so.1+0x38404]
C [pkcs11_softtoken.so.1+0x1f0bc]
C [pkcs11_softtoken.so.1+0x16360] C_EncryptUpdate+0x114
C [libj2pkcs11.so+0x5ac4] Java_sun_security_pkcs11_wrapper_PKCS11_C_1EncryptUpdate+0x194
j sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(JJ[BIIJ[BII)I+90984
j sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(JJ[BIIJ[BII)I+0
j sun.security.pkcs11.P11Cipher.implUpdate([BII[BII)I+57
j sun.security.pkcs11.P11Cipher.engineUpdate([BII[BI)I+18
j javax.crypto.Cipher.update([BII[BI)I+60
j com.sun.net.ssl.internal.ssl.CipherBox.encrypt([BII)I+107
j com.sun.net.ssl.internal.ssl.OutputRecord.encrypt(Lcom/sun/net/ssl/internal/ssl/CipherBox;)V+16
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecordInternal(Lcom/sun/net/ssl/internal/ssl/OutputRecord;)V+13
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Lcom/sun/net/ssl/internal/ssl/OutputRecord;)V+294
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(BB)V+222
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(BLjava/lang/String;Ljava/lang/Throwable;)V+82
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(BLjava/lang/Throwable;)V+4
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(Ljava/lang/Exception;Z)V+112
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(Ljava/lang/Exception;)V+3
j com.sun.net.ssl.internal.ssl.AppInputStream.read([BII)I+82
j java.io.BufferedInputStream.fill()V+175
j java.io.BufferedInputStream.read1([BII)I+44
j java.io.BufferedInputStream.read([BII)I+49
j com.sun.jndi.ldap.Connection.run()V+30
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
V [libjvm.so+0x16b1a4]
V [libjvm.so+0x52e888]
V [libjvm.so+0x1ff2cc]
V [libjvm.so+0x212228]
V [libjvm.so+0x858bf8]
V [libjvm.so+0x77d894]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(JJ[BIIJ[BII)I+0
j sun.security.pkcs11.P11Cipher.implUpdate([BII[BII)I+57
j sun.security.pkcs11.P11Cipher.engineUpdate([BII[BI)I+18
j javax.crypto.Cipher.update([BII[BI)I+60
j com.sun.net.ssl.internal.ssl.CipherBox.encrypt([BII)I+107
j com.sun.net.ssl.internal.ssl.OutputRecord.encrypt(Lcom/sun/net/ssl/internal/ssl/CipherBox;)V+16
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecordInternal(Lcom/sun/net/ssl/internal/ssl/OutputRecord;)V+13
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Lcom/sun/net/ssl/internal/ssl/OutputRecord;)V+294
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(BB)V+222
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(BLjava/lang/String;Ljava/lang/Throwable;)V+82
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(BLjava/lang/Throwable;)V+4
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(Ljava/lang/Exception;Z)V+112
j com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(Ljava/lang/Exception;)V+3
j com.sun.net.ssl.internal.ssl.AppInputStream.read([BII)I+82
j java.io.BufferedInputStream.fill()V+175
j java.io.BufferedInputStream.read1([BII)I+44
j java.io.BufferedInputStream.read([BII)I+49
j com.sun.jndi.ldap.Connection.run()V+30
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
=>0x024e6800 JavaThread "Thread-1144" daemon [_thread_in_native, id=2453, stack(0xa0800000,0xa0880000)]
0x035be000 JavaThread "[STANDBY] ExecuteThread: '40' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=319, stack(0xa0a00000,0xa0a80000)]
0x035bd800 JavaThread "[STANDBY] ExecuteThread: '39' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=318, stack(0xa0b00000,0xa0b80000)]
0x0379d800 JavaThread "[STANDBY] ExecuteThread: '38' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=317, stack(0xa0c00000,0xa0c80000)]
0x0379d400 JavaThread "[STANDBY] ExecuteThread: '37' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=316, stack(0xa0e80000,0xa0f00000)]
0x014d9800 JavaThread "[STANDBY] ExecuteThread: '36' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=313, stack(0xa0f80000,0xa1000000)]
0x012ff400 JavaThread "[STANDBY] ExecuteThread: '35' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=312, stack(0xa1080000,0xa1100000)]
0x01301c00 JavaThread "[STANDBY] ExecuteThread: '34' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=311, stack(0xa1180000,0xa1200000)]
0x0364a000 JavaThread "[STANDBY] ExecuteThread: '33' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=310, stack(0xa1280000,0xa1300000)]
0x017cdc00 JavaThread "[ACTIVE] ExecuteThread: '32' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=309, stack(0xa1380000,0xa1400000)]
0x017cd400 JavaThread "[STANDBY] ExecuteThread: '31' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=308, stack(0xa1480000,0xa1500000)]
0x03d38800 JavaThread "[STANDBY] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=307, stack(0xa1580000,0xa1600000)]
0x03d38000 JavaThread "[ACTIVE] ExecuteThread: '29' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=306, stack(0xa1680000,0xa1700000)]
0x01d2d800 JavaThread "[STANDBY] ExecuteThread: '28' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=305, stack(0xa1780000,0xa1800000)]
0x01d2d400 JavaThread "[STANDBY] ExecuteThread: '27' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=304, stack(0xa1880000,0xa1900000)]
0x01303800 JavaThread "[STANDBY] ExecuteThread: '26' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=281, stack(0xa1980000,0xa1a00000)]
0x01936c00 JavaThread "[STANDBY] ExecuteThread: '25' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=279, stack(0xa1a80000,0xa1b00000)]
0x0177b400 JavaThread "[STANDBY] ExecuteThread: '24' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=242, stack(0xa1c80000,0xa1d00000)]
0x0177a400 JavaThread "[ACTIVE] ExecuteThread: '23' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=241, stack(0xa1d80000,0xa1e00000)]
0x03a8f800 JavaThread "[STANDBY] ExecuteThread: '22' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=240, stack(0xa1b80000,0xa1c00000)]
0x02538800 JavaThread "[ACTIVE] ExecuteThread: '21' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=224, stack(0xa1e80000,0xa1f00000)]
0x03672000 JavaThread "[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=223, stack(0xa1f80000,0xa2000000)]
0x033f3000 JavaThread "[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=222, stack(0xa2080000,0xa2100000)]
0x02534800 JavaThread "[STANDBY] ExecuteThread: '18' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=221, stack(0xa2180000,0xa2200000)]
0x03670000 JavaThread "[STANDBY] ExecuteThread: '17' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=220, stack(0xa2280000,0xa2300000)]
0x016cc400 JavaThread "[STANDBY] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=219, stack(0xa2380000,0xa2400000)]
0x036df000 JavaThread "[STANDBY] ExecuteThread: '15' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=218, stack(0xa2480000,0xa2500000)]
0x02560c00 JavaThread "[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=217, stack(0xa2580000,0xa2600000)]
0x005aa000 JavaThread "[STANDBY] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=216, stack(0xa2680000,0xa2700000)]
0x005aec00 JavaThread "[STANDBY] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=215, stack(0xa2780000,0xa2800000)]
0x01e8f000 JavaThread "[ACTIVE] ExecuteThread: '11' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=214, stack(0xa2880000,0xa2900000)]
0x02509400 JavaThread "[ACTIVE] ExecuteThread: '10' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=213, stack(0xa2980000,0xa2a00000)]
0x025f2000 JavaThread "[STANDBY] ExecuteThread: '9' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=212, stack(0xa2a80000,0xa2b00000)]
0x02562400 JavaThread "[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=211, stack(0xa2b80000,0xa2c00000)]
0x02560400 JavaThread "[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=210, stack(0xa2d80000,0xa2e00000)]
0x03d71c00 JavaThread "[STANDBY] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=103, stack(0xa2e80000,0xa2f00000)]
0x03422400 JavaThread "Timer-3" daemon [_thread_blocked, id=95, stack(0xa2f80000,0xa3000000)]
0x0196c400 JavaThread "[STANDBY] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=94, stack(0xa3080000,0xa3100000)]
0x0196bc00 JavaThread "[STANDBY] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=93, stack(0xa3180000,0xa3200000)]
0x02450c00 JavaThread "[STANDBY] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=92, stack(0xa3280000,0xa3300000)]
0x0180ec00 JavaThread "DynamicListenThread[Default]" daemon [_thread_in_native, id=91, stack(0xa3380000,0xa3400000)]
0x0180e400 JavaThread "[STANDBY] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=90, stack(0xa3480000,0xa3500000)]
0x0252cc00 JavaThread "weblogic.GCMonitor" daemon [_thread_blocked, id=89, stack(0xa3580000,0xa3600000)]
0x0180bc00 JavaThread "weblogic.cluster.MessageReceiver" daemon [_thread_in_native, id=88, stack(0xa3680000,0xa3700000)]
0x02e00800 JavaThread "Timer-2" daemon [_thread_blocked, id=87, stack(0xa3780000,0xa3800000)]
0x03697800 JavaThread "Thread-12" daemon [_thread_blocked, id=86, stack(0xa3880000,0xa3900000)]
0x01f1c400 JavaThread "Thread-11" daemon [_thread_blocked, id=85, stack(0xa3a80000,0xa3b00000)]
0x0155d800 JavaThread "DoSManager" daemon [_thread_blocked, id=84, stack(0xa3980000,0xa3a00000)]
0x01d05800 JavaThread "VDE Transaction Processor Thread" daemon [_thread_blocked, id=82, stack(0xa3b80000,0xa3c00000)]
0x01d48400 JavaThread "ExecuteThread: '32' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=81, stack(0xa3c80000,0xa3d00000)]
0x01d46c00 JavaThread "ExecuteThread: '31' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=80, stack(0xa3d80000,0xa3e00000)]
0x01d45400 JavaThread "ExecuteThread: '30' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=79, stack(0xa3e80000,0xa3f00000)]
0x01d40800 JavaThread "ExecuteThread: '29' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=78, stack(0xa3f80000,0xa4000000)]
0x01d3f000 JavaThread "ExecuteThread: '28' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=77, stack(0xa4080000,0xa4100000)]
0x01d8b400 JavaThread "ExecuteThread: '27' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=76, stack(0xa4180000,0xa4200000)]
0x01d89c00 JavaThread "ExecuteThread: '26' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=75, stack(0xa4280000,0xa4300000)]
0x01d85000 JavaThread "ExecuteThread: '25' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=74, stack(0xa4380000,0xa4400000)]
0x01d83800 JavaThread "ExecuteThread: '24' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=73, stack(0xa4480000,0xa4500000)]
0x01d82000 JavaThread "ExecuteThread: '23' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=72, stack(0xa4580000,0xa4600000)]
0x01d80800 JavaThread "ExecuteThread: '22' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=71, stack(0xa4680000,0xa4700000)]
0x01d7bc00 JavaThread "ExecuteThread: '21' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=70, stack(0xa4780000,0xa4800000)]
0x0167a400 JavaThread "ExecuteThread: '20' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=69, stack(0xa4880000,0xa4900000)]
0x01678c00 JavaThread "ExecuteThread: '19' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=68, stack(0xa4980000,0xa4a00000)]
0x01677400 JavaThread "ExecuteThread: '18' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=67, stack(0xa4a80000,0xa4b00000)]
0x01672400 JavaThread "ExecuteThread: '17' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=66, stack(0xa4b80000,0xa4c00000)]
0x01670c00 JavaThread "ExecuteThread: '16' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=65, stack(0xa4c80000,0xa4d00000)]
0x0166f400 JavaThread "ExecuteThread: '15' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=64, stack(0xa4d80000,0xa4e00000)]
0x006ac000 JavaThread "ExecuteThread: '14' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=63, stack(0xa4e80000,0xa4f00000)]
0x006aa800 JavaThread "ExecuteThread: '13' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=62, stack(0xa4f80000,0xa5000000)]
0x006a9000 JavaThread "ExecuteThread: '12' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=61, stack(0xa5080000,0xa5100000)]
0x0182ac00 JavaThread "ExecuteThread: '11' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=60, stack(0xa5180000,0xa5200000)]
0x01829400 JavaThread "ExecuteThread: '10' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=59, stack(0xa5280000,0xa5300000)]
0x01827c00 JavaThread "ExecuteThread: '9' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=58, stack(0xa5380000,0xa5400000)]
0x01826400 JavaThread "ExecuteThread: '8' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=57, stack(0xa5480000,0xa5500000)]
0x01824c00 JavaThread "ExecuteThread: '7' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=56, stack(0xa5580000,0xa5600000)]
0x01cb7800 JavaThread "ExecuteThread: '6' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=55, stack(0xa5680000,0xa5700000)]
0x01cb3000 JavaThread "ExecuteThread: '5' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=54, stack(0xa5780000,0xa5800000)]
0x01cb1c00 JavaThread "ExecuteThread: '4' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=53, stack(0xa5880000,0xa5900000)]
0x01cdbc00 JavaThread "ExecuteThread: '3' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=52, stack(0xa5980000,0xa5a00000)]
0x01e70800 JavaThread "ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=51, stack(0xa5a80000,0xa5b00000)]
0x01e70000 JavaThread "ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'" daemon [_thread_blocked, id=50, stack(0xa5b80000,0xa5c00000)]
0x00b68000 JavaThread "ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" daemon [_thread_in_native, id=49, stack(0xa5c80000,0xa5d00000)]
0x018e7800 JavaThread "Thread-7" daemon [_thread_blocked, id=48, stack(0xa5d80000,0xa5e00000)]
0x018d1400 JavaThread "[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=47, stack(0xa5e80000,0xa5f00000)]
0x01896000 JavaThread "weblogic.timers.TimerThread" daemon [_thread_blocked, id=46, stack(0xa5f80000,0xa6000000)]
0x00ad4c00 JavaThread "weblogic.time.TimeEventGenerator" daemon [_thread_blocked, id=45, stack(0xa6080000,0xa6100000)]
0x00ad6800 JavaThread "[STANDBY] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_blocked, id=44, stack(0xa6180000,0xa6200000)]
0x01d38000 JavaThread "Timer-1" daemon [_thread_blocked, id=43, stack(0xa6280000,0xa6300000)]
0x0194cc00 JavaThread "Timer-0" daemon [_thread_blocked, id=42, stack(0xa6380000,0xa6400000)]
0x005e0000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=40, stack(0xa6880000,0xa6900000)]
0x005dcc00 JavaThread "CompilerThread1" daemon [_thread_blocked, id=39, stack(0xa6980000,0xa6a00000)]
0x005db000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=38, stack(0xa6a80000,0xa6b00000)]
0x005d9800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=37, stack(0xa6b80000,0xa6c00000)]
0x005d8400 JavaThread "Surrogate Locker Thread (CMS)" daemon [_thread_blocked, id=36, stack(0xa6c80000,0xa6d00000)]
0x005c1800 JavaThread "Finalizer" daemon [_thread_blocked, id=35, stack(0xa6d80000,0xa6e00000)]
0x005c0000 JavaThread "Reference Handler" daemon [_thread_blocked, id=34, stack(0xa6e80000,0xa6f00000)]
0x00043000 JavaThread "main" [_thread_blocked, id=2, stack(0xfe300000,0xfe380000)]
Other Threads:
0x005bb800 VMThread [stack: 0xa6f80000,0xa7000000] [id=33]
0x005ea400 WatcherThread [stack: 0xa6780000,0xa6800000] [id=41]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
par new generation total 31680K, used 7698K [0xaa800000, 0xaca50000, 0xb2800000)
eden space 28224K, 24% used [0xaa800000, 0xaaec03c0, 0xac390000)
from space 3456K, 22% used [0xac390000, 0xac4547c0, 0xac6f0000)
to space 3456K, 0% used [0xac6f0000, 0xac6f0000, 0xaca50000)
concurrent mark-sweep generation total 441048K, used 181900K [0xb2800000, 0xcd6b6000, 0xea800000)
concurrent-mark-sweep perm gen total 206792K, used 124256K [0xea800000, 0xf71f2000, 0xfa800000)
Dynamic libraries:
0x00010000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/bin/java
0xff3a0000      /lib/libthread.so.1
0xff370000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/bin/../jre/lib/sparc/jli/libjli.so
0xff350000      /lib/libdl.so.1
0xff200000      /lib/libc.so.1
0xff390000      /platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1
0xfe400000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/server/libjvm.so
0xff1d0000      /lib/libsocket.so.1
0xff1f0000      /usr/lib/libsched.so.1
0xff1b0000      /lib/libm.so.1
0xff180000      /usr/lib/libCrun.so.1
0xff160000      /lib/libdoor.so.1
0xff080000      /lib/libnsl.so.1
0xfef80000      /lib/libm.so.2
0xff050000      /lib/libscf.so.1
0xff140000      /lib/libuutil.so.1
0xfef60000      /lib/libgen.so.1
0xfef30000      /lib/libmd.so.1
0xfef10000      /lib/libmp.so.2
0xfee80000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/libverify.so
0xfe3c0000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/libjava.so
0xfee60000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/native_threads/libhpi.so
0xfe2c0000      /lib/nss_files.so.1
0xfe2a0000      /lib/nss_nis.so.1
0xfe280000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/libzip.so
0xfacd0000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/libnet.so
0xfacb0000      /lib/nss_dns.so.1
0xfaba0000      /lib/libresolv.so.2
0xfac90000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/libmanagement.so
0xaa790000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/libnio.so
0xaa4e0000      /lib/librt.so.1
0xaa2e0000      /lib/libaio.so.1
0xaa2c0000      /usr/lib/libsendfile.so.1
0xaa290000      /lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/libj2pkcs11.so
0xaa0d0000      /usr/lib/libpkcs11.so
0xaa190000      /usr/lib/libcryptoutil.so.1
0xa7ba0000      /usr/lib/security/pkcs11_softtoken.so
0xaa0b0000      /lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/native/solaris/sparc/libstackdump.so
0xa7ae0000      /lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/native/solaris/sparc/libwlfileio2.so
0xa7ac0000      /lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/native/solaris/sparc/libmuxer.so
0xa7aa0000      /usr/ucblib/libucb.so.1
0xa79d0000      /lib/libelf.so.1
VM Arguments:
jvm_args: -Dabat001 -Xms256m -Xmx1024m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:GCTimeRatio=19 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:+JavaMonitorsInStackTrace -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/sites/abat/site/live/wls103/../../common/logs/103_abat001/gc.log -Xverify:none -da -Dplatform.home=/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3 -Dwls.home=/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server -Dweblogic.home=/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server -Ddomain.home=/sites/abat/site/live/wls103 -Dweblogic.security.SSL.enforceConstraints=off -Dlog4j.configuration=file:/sites/abat/site/live/wls103/properties/log4j.xml -Dweblogic.management.discover=false -Dweblogic.management.server=t3://vmcdaw70.naeng.gm.com:9803 -Dwlw.iterativeDev=false -Dwlw.testConsole=false -Dwlw.logErrorsToConsole= -Dweblogic.ext.dirs=/lapps/wls103/usr/local/oracle/wls103/patch_wlw1030/profiles/default/sysext_manifest_classpath:/lapps/wls103/usr/local/oracle/wls103/patch_wls1030/profiles/default/sysext_manifest_classpath:/lapps/wls103/usr/local/oracle/wls103/patch_cie660/profiles/default/sysext_manifest_classpath -Dweblogic.Name=abat001 -Djava.security.policy=/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/lib/weblogic.policy
java_command: weblogic.Server
Launcher Type: SUN_STANDARD
Environment Variables:
JAVA_HOME=/lapps/wls103/usr/local/oracle/wls103/currentjdk
CLASSPATH=/sites/abat/site/live/wls103/properties:::/lapps/wls103/usr/local/oracle/wls103/patch_wlw1030/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/lapps/wls103/usr/local/oracle/wls103/patch_wls1030/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/lapps/wls103/usr/local/oracle/wls103/patch_cie660/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/lapps/wls103/usr/local/oracle/wls103/currentjdk/lib/tools.jar:/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/lib/weblogic_sp.jar:/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/lib/weblogic.jar:/lapps/wls103/usr/local/oracle/wls103/modules/features/weblogic.server.modules_10.3.0.0.jar:/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/lib/webservices.jar:/lapps/wls103/usr/local/oracle/wls103/modules/org.apache.ant_1.6.5/lib/ant-all.jar:/lapps/wls103/usr/local/oracle/wls103/modules/net.sf.antcontrib_1.0.0.0_1-0b2/lib/ant-contrib.jar:::/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/lib/xqrl.jar::
PATH=/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/bin:/lapps/wls103/usr/local/oracle/wls103/modules/org.apache.ant_1.6.5/bin:/lapps/wls103/usr/local/oracle/wls103/currentjdk/jre/bin:/lapps/wls103/usr/local/oracle/wls103/currentjdk/bin:/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/bin:/lapps/wls103/usr/local/oracle/wls103/modules/org.apache.ant_1.6.5/bin:/lapps/wls103/usr/local/oracle/wls103/currentjdk/jre/bin:/lapps/wls103/usr/local/oracle/wls103/currentjdk/bin:/usr/xpg4/bin:/usr/bin:/usr/sbin:/usr/ucb:/usr/openwin/bin:/common/site/scripts:/common/ce/scripts:/common/site/bin:/common/ce/bin:/common/gm/scripts:/common/gm/bin:/opt/EMCpower/bin:/etc
LD_LIBRARY_PATH=/lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc/server:/lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/lib/sparc:/lapps/wls103/usr/local/oracle/wls103/jdk1.6.0_24/jre/../lib/sparc:/lapps/wls103/usr/local/oracle/wls103/patch_wlw1030/profiles/default/native:/lapps/wls103/usr/local/oracle/wls103/patch_wls1030/profiles/default/native:/lapps/wls103/usr/local/oracle/wls103/patch_cie660/profiles/default/native::/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/native/solaris/sparc:/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/native/solaris/sparc/oci920_8:/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/native/solaris/sparc:/lapps/wls103/usr/local/oracle/wls103/wlserver_10.3/server/native/solaris/sparc/oci920_8
SHELL=/bin/ksh
Signal Handlers:
SIGSEGV: [libjvm.so+0x8b1aa0], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGBUS: [libjvm.so+0x8b1aa0], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGFPE: [libjvm.so+0x1d21a4], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGPIPE: [libjvm.so+0x1d21a4], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGXFSZ: [libjvm.so+0x1d21a4], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGILL: [libjvm.so+0x1d21a4], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGQUIT: [libjvm.so+0x78003c], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGHUP: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGTERM: [libjvm.so+0x78003c], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIG39: [libjvm.so+0x783744], sa_mask[0]=0x00000000, sa_flags=0x00000008
SIG40: [libjvm.so+0x1d21a4], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
--------------- 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_138888-06 sun4u (T2 libthread)
rlimit: STACK 8192k, CORE infinity, NOFILE 65536, AS infinity
load average:2.25 1.43 1.14
CPU:total 32 has_v8, has_v9, popc, has_vis1, has_vis2, is_ultra3
Memory: 8k page, physical 134217728k(72609456k free)
vm_info: Java HotSpot(TM) Server VM (19.1-b02) for solaris-sparc JRE (1.6.0_24-b07), built on Feb 2 2011 17:17:59 by "" with Workshop 5.8
time: Wed May 25 01:40:22 2011
elapsed time: 263652 seconds
Appreciate your help thanks :
K.Vickram
Edited by: Vickram on May 25, 2011 12:35 PM

Hi Rohit Jaiswal
Thanks rohit for the quick response
just to understand
You mean to say " It is not an JVM crash "
Is that say JVM is having issue with Solaris OS. or crash in OS ?
We are not using native code in our application .
if possible elobrate the above .
we are in process to raise an oracle case
Reagards,
K.Vickram

Lot of core files are generated in webserver machine.......

we have a iplanet webserver running in our production environment........it is creating lot of entries in the file /var/adm/messages...............
Aug 11 13:00:01 uk17 sendmail[1449]: [ID 702911 mail.warning] gethostbyaddr(192.168.245.62) failed: 1
Aug 11 13:00:01 uk17 sendmail[1449]: [ID 702911 mail.warning] gethostbyaddr(192.168.245.64) failed: 1
Aug 11 13:00:01 uk17 sendmail[1449]: [ID 702911 mail.warning] gethostbyaddr(192.168.245.84) failed: 1
Aug 11 13:00:01 uk17 sendmail[1449]: [ID 702911 mail.warning] gethostbyaddr(192.168.245.88) failed: 1
Aug 11 13:00:01 uk17 sendmail[1449]: [ID 702911 mail.warning] gethostbyaddr(192.168.245.90) failed: 1
Aug 11 13:00:01 uk17 sendmail[1449]: [ID 702911 mail.warning] gethostbyaddr(192.168.245.92) failed: 1
Aug 11 13:00:01 uk17 sendmail[1449]: [ID 702911 mail.warning] gethostbyaddr(192.168.245.94) failed: 1
Aug 11 13:00:01 uk17 sendmail[1449]: [ID 702911 mail.warning] gethostbyaddr(192.168.245.106) failed: 1
Aug 11 13:00:01 uk17 sendmail[1449]: [ID 702911 mail.warning] gethostbyaddr(192.168.245.108) failed: 1
Aug 11 13:00:01 uk17 sendmail[1449]: [ID 702911 mail.warning] gethostbyaddr(192.168.245.110) failed: 1
It is creating lot of core files in /var/core/ with the name.......
ore.ns-httpd.14156.uk17.0.0.1218243851
core.ns-httpd.14922.uk17.0.0.1217950925
core.ns-httpd.14922.uk17.0.0.1217950926
core.ns-httpd.14937.uk17.0.0.1218243696
core.ns-httpd.14937.uk17.0.0.1218243697
core.ns-httpd.14949.uk17.0.0.1218243760
core.ns-httpd.14949.uk17.0.0.1218243762
core.ns-httpd.14955.uk17.0.0.1218243765
core.ns-httpd.14955.uk17.0.0.1218243767
core.ns-httpd.14977.uk17.0.0.1218243777
those files are in byte code so unable to read those file.............
Please any one help me on this issue...............

First migrate your server to the latest Web Server 7.0 update 3
http://www.sun.com/software/products/web_srvr/index.xml
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=SJWS-7.0U3-OTH-G-F@CDS-CDS_SMI
You are getting those messages as gethostbyaddr(192.168.245.92) is failing. Try writing a small C program which calls gethostbyaddr(192.168.245.92) and see if its an o/s issue.
If you are on Solaris 10 try to see why Web Server is dumping core by
mdb core.pid
::stackAre you sure you have patch levels as recommended in the release notes of Web Server?
Have you enabled IPv6? Since when are you seeing these core dumps?

Dbx - core file without symbolic info - from C++ app

I have multiple core files, written by a C++ application (with C++ shared libs also) which has been 'strip'ed of all symbolic info. I have been able to determine that all cores happen in the same method, with the same stack trace showing for each. Using the mdb $m cmd I can track the location down to a particular shared library.
Is there some way to now track it down further regarding where in the shared lib the event occured? Something like getting an offset map of the items in the shared lib, and using their offset into the library listing, match that against the offset of the address of the method which trapped as an offset from the process base address?
I am at a loss as to how to proceed any further here. Can someone enlighten me as to the next steps I can take?
Thx...

compiler: Sun Workshop 6 - update 2
OS: Solaris 5.8
When I do pstack or dbx-->where cmd, I get:
----------------- lwp# 15315 / thread# 1 --------------------
ffffffff7ec5653c ???????? (101d80ed0, 1, 6872b020c49ba5e3, 3fff9e353f7ced91, ffffffff7eca7db8, 0)
ffffffff7ec55374 ???????? (10125fac0, 101d86d30, 101c8be60, 101da03f0, 101da03f0, ffffffff7edab9e0)
ffffffff7ec47920 ???????? (101d86d30, ffffffff7fffe0e8, 101055900, 0, 1005cdca0, 1001dfd88)
ffffffff7ec5ed94 ???????? (101b6f620, ffffffff7fffe0e8, ffffffff7fffe530, 1003cab90, 101052040, 0)
ffffffff7e15a7c8 ???????? (1005cb2b0, 466, 1001e2710, ffffffff7fffe530, 1003cab90, 0)
ffffffff7ec5d49c ???????? (ffffffff7fffe530, 1005cb308, 1001dfd88, 1003cab90, 1003cab90, 1005cb2b0)
ffffffff7ec65ee4 ???????? (466, 1001e2710, ffffffff7fffe530, 1003cab90, 466, 1001e2740)
0000000100029dd0 ???????? (1001e2745, 466, ffffffff7fffee20, 0, 0, 0)
000000010002989c ???????? (0, 0, 0, 0, 0, 0)
No symbolic information. But trap happened at 7ec5653c .
Now if I do a dump -t on the process binary to dump the symbol table, I get a listing like:
ffffffff7c200000 ffffffff7c2a8000 a8000 /usr/lib/sparcv9/libnsl.so.1
ffffffff7c3a8000 ffffffff7c3b8000 10000 /usr/lib/sparcv9/libnsl.so.1
ffffffff7c3b8000 ffffffff7c3c0000 8000 /usr/lib/sparcv9/libnsl.so.1
ffffffff7c400000 ffffffff7cf1e000 b1e000 /ap/p/cc/oracle/product/9.2.0/lib/libclntsh.so.9.0
ffffffff7d01c000 ffffffff7d0d0000 b4000
ffffffff7d0d0000 ffffffff7d0e2000 12000
ffffffff7d100000 ffffffff7d102000 2000
ffffffff7d200000 ffffffff7d296000 96000 /ap/p/cc/tss/curr/lib/libwhatever1.so
ffffffff7d394000 ffffffff7d39c000 8000
ffffffff7d400000 ffffffff7d56c000 16c000 /ap/p/cc/tss/curr/lib/libwhatever2.so
ffffffff7d66a000 ffffffff7da72000 408000
ffffffff7db00000 ffffffff7db02000 2000 /usr/lib/sparcv9/libdl.so.1
ffffffff7dc00000 ffffffff7dc02000 2000
ffffffff7dd00000 ffffffff7dd02000 2000
ffffffff7de00000 ffffffff7de8c000 8c000 /ap/p/cc/tss/applib/libapputility64.so
ffffffff7df8a000 ffffffff7df92000 8000
ffffffff7e000000 ffffffff7e18a000 18a000 /ap/p/cc/tss/applib/libwhatever364.so
ffffffff7e288000 ffffffff7e296000 e000
ffffffff7e296000 ffffffff7e47e000 1e8000
ffffffff7e500000 ffffffff7e538000 38000 /ap/p/cc/tss/applib/libwhatever4.so
ffffffff7e636000 ffffffff7e63a000 4000
ffffffff7e700000 ffffffff7e71e000 1e000 /ap/p/cc/tss/applib/libdatabase64.so
ffffffff7e81c000 ffffffff7e820000 4000
ffffffff7e900000 ffffffff7e904000 4000 /ap/p/cc/tss/pcontrol/../bin/libtscalltcp014.so
ffffffff7ea02000 ffffffff7ea04000 2000
ffffffff7ea04000 ffffffff7ebec000 1e8000
ffffffff7ec00000 ffffffff7ecac000 ac000 /ap/p/cc/tss/curr/lib/libthis_is_it.so
--> note: happened in libthis_is_it.so at 7ec5653c
ffffffff7edaa000 ffffffff7f028000 27e000
ffffffff7f100000 ffffffff7f144000 44000 /ap/p/cc/tss/pcontrol/../bin/libwhatever5.so
ffffffff7f242000 ffffffff7f24e000 c000
ffffffff7f24e000 ffffffff7f258000 a000
ffffffff7f300000 ffffffff7f302000 2000
f
I see a shared lib occupying from 7ec00000 to 7ecac000, and my trap address falls within that range. So I believe I can narrow the event to that particular shared lib based on that. Correct?
Now I do a dump -t on that particular shared lib, and I wind up with another listing. Grep that listing for string values between 0x55 and 0x56, I find the unit within which the trap address falls, and I have my source location. Like so:
grep -i 0x55 dump_new_symtbl.txt
================================
[1621] 0x55020 24 1 0 0 0x9 ___const_seg_900000504
[1632] 0x55ac0 24 1 0 0 0x9 ___const_seg_900000904
[1634] 0x55f00 24 1 0 0 0x9 ___const_seg_900001102
[2807] 0x55050 2668 2 1 0 0x9 __1cMangledName_1_here
[2877] 0x55af0 1036 2 1 0 0x9 __1cMangledName_2_here
[3017] 0x55f18 3060 2 1 0 0x9 __1cMangledName_3_here
grep -i 0x56 dump_new_symtbl.txt
================================
[1643] 0x56b10 24 1 0 0 0x9 ___const_seg_900001901
[2584] 0x56b40 3656 2 1 0 0x9 __1cMangledName_4_here
I don't really need C++filt in this case, I can discern what the mangled name refers to in the source code.
So I think I have my problem area pin-pointed, I just want to make sure, and have someone knowledgable in this type of analysis to tell me that I an correct.
Thanks for the response.
-mc

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

OEM Grid generating too many core files

Hi all,
Database: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
OEM (OMS and Agent): 10.2.0.5
OS: Solaris 10 (SPARC 64bit)
I have a weird problem concerning the agent, each an every time I start the agent, the cdump directory will be filled with hundreds of core files (66 MB each), thus feeling up the whole filesystem where the cdump directory resides. I'm not sure why this is happening. Is this a bug? Has anyone experienced this before?
Thanks in advance for your help.
Regards,
Durbanite - South Africa

Hi again,
This is the content of the alert log:
bash-3.00$ tail alert_clpr1.log
ORA-07445: exception encountered: core dump [00000001002258A4] [SIGBUS] [Invalid address alignment] [0x60708090A0B0002] [] []
Fri Jul 17 10:01:11 2009
Errors in file /udd001/app/oracle/admin/clpr/udump/clpr1_ora_27740.trc:
ORA-07445: exception encountered: core dump [00000001002258A4] [SIGBUS] [Invalid address alignment] [0x60708090A0B0002] [] []
bash-3.00$ tail /udd001/app/oracle/admin/clpr/udump/clpr1_ora_27839.trc
FD6C6EF9:00005D6A 265 0 10280 1 0x0000000000000109
F3FED575:00005992 266 0 10280 1 0x000000000000010A
FD6E1007:00005D6B 266 0 10280 1 0x000000000000010A
F40260C6:00005994 267 0 10280 1 0x000000000000010B
F40735E8:00005995 268 0 10280 1 0x000000000000010C
F40C0992:00005997 269 0 10280 1 0x000000000000010D
F40F9C50:00005999 270 0 10280 1 0x000000000000010E
KSTDUMP: End of in-memory trace dump
ssexhd: crashing the process...
Shadow_Core_Dump = PARTIAL
I think I might need to contact Oracle Supprt for this one, I'll start by using the ORA-07445 tool on metalink.
Thanks and regards,
Durbanited

Dbx uses 6GB (and counting) loading core file

I'm trying to load a core file in dbx, but it just keeps using memory (I killed it after 6GB resident size). It sits at the prompt
Reading conv
where conv is the executable.
The core file is 4.5M in size, the executable is 680kB. The program was compiled with gcc 3.4 as a 64-bit binary with debugging symbols - should dbx be able to load that? I've tried gdb from the sun.com Solaris Freeware page, however that seems unable to handle 64-bit programs.
We're running on Solaris 10, using dbx 7.5 2005/10/13 from Sun Studio 11.

Some questions:
- what happens if you just debug the executable w/o a corefile?
- Is the 680kB executable size a "text" size or "ls" size?
- Is your gcc producing stabs or DWARF?

System Hung frequently Generates Core file

Hi All,
One of my workstation is getting hung frequently when i kill that session it generates core file and the details are as follows.
Hardware : Sun Blade 2500
Memory: 2 GB
Operating System : Solaris 8 2/04
Patch Version : Generic_117350-12
I found following error in core file:
XtToolkitError.XtToolkitError
CancelDrag
typeConversionError.noConverter
typeConversionError.noConverter
files.so/usr/lib/locale/C/LC_CTYPE/textboundary.so.1
override
rter registered for 'Pixel' to 'SelectColor' conversion.
No type converter registered for 'Pixel' to 'SelectColor' conversion.
ListKbdCancel
Cp9{
override
No type converter registered for '%s' to '%s' conversion.
No type converter registered for '%s' to '%s' conversion.
Please help me to fix this issue.
Thanks & Regards,
Ramana

Hi,
These files are getting generated because your JVM is getting crashed frequently.
When JVM crash, JVM captures the state of the JVM at the time of crash and these files generate.
Please study your std_server log very carefully and you will find some lines like "Out of Memory" kind of error.
Now if you can stop the crash of the JVM, these files wont generate any more.
I have faced the same issue and Fix it using the following ways.
1) Upgrade your JVM to the latest version so that better memory management will be in place.
2) If still these files getting generated, you can tune the new version of the JVM.
With Regards,
Saurabh

Core File Support

Hello,
I'm not sure if this is the correct forum for my question but this looks like the best one.
We have an large application written in 'c' that runs on SunOS 5.8 Generic February 2000
(a.k.a. Solaris 8). We have an internal debugger which our developer's use to debug
our application. We're in the process of trying to add core file support to the debugger.
What's the best way to get to the dynamic linker's link map at the time of the core file dump?
I've looked at the Linker and Libraries Guide, the rtld_debugger_interface for agents and the rd_loadobj_iter but they seem to be more for targeting a running process. I know the link map is somewhere in the core file I'm just not sure how to get at it. Any help is appreciated.
Regards,
Jim

The core(4) man page describes the core file format. The elf(3ELF) man page describes the libelf library that may be used to read the file. In particular, look at elf32_getphdr(3ELF). You can also use "dump -ov core" to see the same information.
Richard

Why dbx core dumps on input core file?

Hi,
We have a Solaris 10 machine, on which dbx always core dumps when input any core files to it. What would possibly wrong with this machine? Or where should we look to find some clues?
Thanks a lot,
pam

Please create a perl script using the text below:
#!/usr/bin/perl
use File::Find;
sub wanted {
return unless -x && -f;
return unless /.*\.so\.[0-9]$/;
return unless `/bin/file $_ | grep 64-bit`;
$out = `elfdump -e $_ | grep e_shoff`;
$out =~ m/e_shoff:\s+(0x[0-9a-f]+)\s/;
if ($1 =~ m/[4c]$/) {
print "bad alignment in file: $File::Find::name\n";
print "Looking for bad ELF section header table alignment in 64-bit files\n";
find(\&wanted, ( "/lib", "/usr/lib" ));Then, make it executable and run it (does not need root permissions):
any_user$ chmod +x check_library_alignment.pl
any_user$ ./check_library_alignment.pl
If the perl script reports mis-aligned libraries (elfsign modifies the alignment), this looks to be bug 6283299. If you are current on patches for Solaris as well as your SunStudio installation, you'll need to raise an SR requesting the fix. If you are not current on patches, you could start with SunStudio patches which was subsequently patched to address elfsign alignments.
Source: http://technopark02.blogspot.com/2006/01/64-bit-dbx-internal-error-signal.html

Core file

Hi Guys...
I am running Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production on Solaris.
Today this morning my O/S creates a core file and when I check the information about that file.
The details of the file using "file core" commands are like this:
core: ELF 64-bit MSB core file SPARCV9 Version 1, from 'oracle'
This clearly show me that the file comes from oracle.
Now I want obtain more information about that file.
Please help!!!!!!!!!!!!!!!!!!!!!!

Dear user11979518,
If you do have a core file or similiarly an ORA-600 error that needs to be analyzed from a technical support guy. We, at least i am not the Oracle support so that is why you need to check metalink or even raise an SR call.
By the way, i will be glad if you can post the solution (not the metalink article) here.
Regards.
Ogan

Core file in solaris

Similar Messages

Maybe you are looking for