DBX and Core File

HI,
We just moved our product from Solaris 8 to Solaris 10. It did not have any problem running on Solaris 8. However it core dumped on Solaris 10 after running 2 weeks (bus error). What's confusing is that I can not even use dbx to look at the core file. DBX cored dumped on the core file. I have to use gdb.
Does anyone else run into the problem? I am suspecting we have not set up some vary basic things right, or it's a known problem that dbx does not work on Solaris 10?
Your help is very much appreciated,
pam

Hi Andrew,
Again appreciate your help very much.
Got the same result (core dumped) by7 looking at the core file on the same machine that the crash was generated.
I found this one:
http://blogs.sun.com/quenelle/entry/two_bad_solaris_bugs_that
Bug 6283570 might be the cause. So we are all set here, if I am correct.
Thanks again,
pam

Similar Messages

Attempting to install LiveCycle and English and Core .cab files aren't recognized and then mysteriously disappear

I am attempting to install the free 60-day trial of LiveCycle ES4. It downloads all files into the temp folder. When I begin install I can see the English and Core files in same folder. Install reaches a certain point and then states it can't recognize one or both of those files and tells me to ensure they exist and are accessible. Once I do they both disappear

Please read this whole message before doing anything.
This procedure is a diagnostic test. It’s unlikely to solve your problem. Don’t be disappointed when you find that nothing has changed after you complete it.
The purpose of this exercise is to determine whether the problem is caused by third-party system modifications that load automatically at startup or login. Disconnect all wired peripherals except those needed for the test, and remove all aftermarket expansion cards. Boot in safe mode* and log in to the account with the problem. The instructions provided by Apple are as follows:
Be sure your Mac is shut down.
Press the power button.
Immediately after you hear the startup tone, hold the Shift key. The Shift key should be held as soon as possible after the startup tone, but not before the tone.
Release the Shift key when you see the gray Apple icon and the progress indicator (looks like a spinning gear).
*Note: If FileVault is enabled under Mac OS X 10.7 or later, you can’t boot in safe mode.
Safe mode is much slower to boot and run than normal, and some things won’t work at all, including wireless networking on certain Macs.
The login screen appears even if you usually log in automatically. You must know your login password in order to log in. If you’ve forgotten the password, you will need to reset it before you begin.
Test while in safe mode. Same problem(s)?
After testing, reboot as usual (i.e., not in safe mode) and verify that you still have the problem. Post the results of the test.

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?

Dbx against core and recompiled sources

Hi,
We are trying to run dbx on a core file for which we have the original executable and libs, but not the source / object tree. We have recompiled the objects from the original source, but dbx complains that they were compiled at a different time, and refuses to read them:
Object file: <pathname>/server.o
compiled on: Mon Oct 4 13:50:43 2004
Executable contains object file compiled on: Sun Mar 28 10:19:30 2004
dbx: warning: Object file is not the same one that was linked into executable.
Skipping stabs. (see `help finding-files')
How can we force dbx to ignore the compiled-in date stamps and read the object files? Here's the dbx version info:
Dbx Debugger 7.0 Patch 111709-02 2002/07/09
And the output of 'uname -a':
SunOS ex2-ssmsun1 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-2
Thanks,
Chris

This version - Forte Developer 7 has been announced EOL(End of Life). If you have support contract with Sun, please follow the service channel and seek help.
http://developers.sun.com/tools/cc/support/support_matrix.html
Otherwise, we strongly recommend you to upgrade to the current version Sun Studio 9 which could be found at:
http://wwws.sun.com/software/products/studio/index.html
The dbx version is 7.3 in Sun Studio 9.
Thanks.
Rose

Debugging core files with dbx

Here are a few questions one of our developers asked me
to post:
There are some things I don't understand about these core files.
(I get this dbx message examining the core file: dbx: internal warning: writable memory segment 0xfe750000[188416] of size 0 in core)
Here are the threads:
(dbx) threads
> t@1 a l@1 ?() LWP suspended in elflookup_filtee()
t@2 a l@2 ?() LWP suspended in __open()
t@4 b l@4 kaiocleanup_thread() LWP suspended in kaio()
o t@5 a l@5 ?() signal SIGSEGV in runThreadFunction()
t@6 a l@6 ?() sleep on (unknown) in __lwp_park()
t@7 a l@7 ?() sleep on (unknown) in __lwp_park()
(dbx)
Here's thread 1:
(dbx) where
current thread: t@1
=>[1] elflookup_filtee(0xffbff29c, 0xffbff32c, 0xffbff328, 0x5af8f2f, 0x184, 0xff1208d8), at 0xff3b8e3c
[2] lookup_sym_interpose(0xffbff330, 0xffbff32c, 0xffbff328, 0x5af8f2f, 0x0, 0xff3c2bcc), at 0xff3b6a2c
[3] tls_report_modules(0xff3ec0f0, 0xfea905d0, 0x2380c, 0xff3ec0f0, 0xff3ee67c, 0x0), at 0xff3caeac
[4] rtboot(0x2380c, 0xff000000, 0x0, 0xfe8b6448, 0x0, 0xfe8e9c44), at 0xff3b378c
[5] 0x4aee0(0x4bfd8, 0x0, 0xff000000, 0x0, 0x0, 0xfe7f2000), at 0x4aedf
[6] 0x2380c(0x1, 0x1084, 0xfe797cc0, 0x0, 0xfe7f2000, 0x1000), at 0x2380b
[7] _exithandle(0xfe8e9b80, 0xfe797c00, 0xfe8e8bc0, 0x1, 0x4b104, 0xfc00), at 0xfe83e608
[8] exit(0x0, 0x1, 0x77c20, 0x4d000, 0xfe7974c0, 0xfe797500), at 0xfe82cf28
And here's thread 5:
(dbx) where -h
current thread: t@5
=>[1] DataWriter::runThreadFunction(0xffbff1a0, 0x0, 0x431bde83, 0x15a758, 0x0, 0x9f3e), at 0x1eba8
[2] 0xfeee5724(0xffbff1ac, 0xfe47c000, 0x0, 0x0, 0xffbff1a0, 0x4bb1c), at 0xfeee5723
(dbx)
What I dont understand:
1. Why is where on thread 5 not reporting the SEGV?
2. Why is thread 1 in the exit handle when some threads have not yet exited?
3. Why is thread 1 not showing any stack above the exit call?
How do I get information on these questions?
Thanks in advance.
-- prasad

which version of dbx are you using?
A message about "size 0" can sometimes mean that
your core file was truncated by a core limit that is set
too low. That can cause missing information.
1. Why is where on thread 5 not reporting the SEGV?I don't know. This seems like a bug, but not a serious one.
You know there is a seg fault from the "threads" command.
2. Why is thread 1 in the exit handle when some threads have not yet exited?The program can call exit() whenever it wants to. At that
point the cleanup handlers will be called. If you want the
system to wait for all threads to exit, then call thr_exit() instead
of exit().
3. Why is thread 1 not showing any stack above the exit call?I don't know the answer. Sometimes stack trace information
in the process is a little but unreliable. It's only 100% reliable if you
compile with -g and do not use the optimizer. Even in those cases,
it is 99% reliable.

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

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

Debugging core file with dbx

I am trying to debug a core file with dbx. My first problem was a core mismatch. I copied the libraries from production to a directory in my development environment, set core_lo_pathmap to on, and used the pathmap command to get the files from the new location. The files I copied include ld.so and ld.so.1 - based on an article I read. I am not getting the core mismatch anymore but this is the result I am getting now:
Reading libdec.so
Reading libhpsnls.so
Reading libc_psr.so.1
Reading libthread.so.1
Reading nss_files.so.1
Reading GMOG1.dll
Reading vogn2405.dll
Reading libiiapi.1.so
detected a multithreaded program
t@1 (l@1) terminated by signal SEGV (no mapping at the fault address)
0xff311c5c: fflushu_iops+0x004c: ldub [%i4 + 0xc], %o0
I am unsure of the next step and any advice would be appreciated.

If all you're looking for is a stack trace, run pstack on the core file on the
production system where the core was created.
tim

Problems w/dbx on custom binary and core

Hi, y'all. I'm a developer for VMware's virtual machine monitor group. I'm a big fan of dbx, and would love to kick gdb to the curb as my workaday debugger. Unfortunately, dbx seems to be having some trouble with our environment. I'm using custom ELF binaries produced by our own linker, along with core files that come from our own dumper. A typical session follows:
$ dbx -f vmm64 vmware64-core1
Reading vmm64
dbx: warning: program has entry point of 0
dbx: warning: The corefile was truncated.
It should have been 123969840 bytes long (is only 123969839)
Because of this, some functionality will be missing from dbx.
(See `help core')
core file header read successfully
program terminated by signal SEGV (Segmentation fault)
0xffffffffffffffff: <bad address 0xffffffffffffffff>
dbx: core file read error: address 0xffff81007fea5e90 not in data space
dbx: attempt to read frame failed -- cannot get return address
dbx: warning: No frame with source found
(dbx) where
[1] 0xfffffffffc2cefc6(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc2cefc6
[2] 0xfffffffffc2cf31b(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc2cf31b
[3] 0xfffffffffc240fa6(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xffff00000000, 0xfffffffffc2224b0, 0xfffffffffc048df0, 0xfffffffffc001000, 0xfffffffffc048de0, 0xfffffffffc241320, 0xfffffffffc048f40, 0xfffffffffc31b5d0, 0xfffffffffc048ec0, 0xfffffffffc29f9cb, 0x3000000008, 0xfffffffffc048ed0), at 0xfffffffffc240fa6
[4] 0xfffffffffc29fcb8(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc29fcb8
[5] 0xfffffffffc241320(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc241320
[6] 0xfffffffffc29f9cb(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc29f9cb
[7] 0xfffffffffc2dc7ae(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc2dc7ae
[8] 0xfffffffffc2cf928(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc2cf928
[9] 0xfffffffffc317554(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc317554
[10] 0xfffffffffc31b5d5(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc31b5d5
[11] 0xfffffffffc2dcae1(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc2dcae1
[12] 0xfffffffffc2cf928(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffffffc2cf928
I bet the off-by-one error in the core file is our fault. The fanciful backtrace is a little harder to make sense of; we're using frame pointers n' stuff. All of those virtual addresses look like they're part of the stack to me; any idea what we're doing to prevent dbx from picking up the RIP?
Examining globals seems to work ok:
(dbx) p VC
VC = 0xfffffffffc019000
(dbx) p gPhysL3MPNs
gPhysL3MPNs = (1898348U, 1818511U, 0, 0, 0, 0, 0, 0)
Text symbols are dandy enough:
(dbx) l BT_Init
122 *----------------------------------------------------------------------
123 */
124 void
125 BT_Init(void)
126 {
It seems like it's just the stack frames that are giving dbx fits. Any thoughts? My guess is that we're doing something wrong, either in our core file or our ELF file.

I have this suggestion:
- create a file named C.dbx with the following content:
options -file L.dbx
LogFrame
LogReg
LogRegSet
LogStateful
- run dbx, issue all the same commands that you issued, then exit and see if L.dbx appeared in the same (working) directory. It should be there.
- once you have L.dbx, please send it to kms [at) sun dot com
I'll try to reconstruct what's going on.
Edited by: MaximKartashev on Oct 26, 2007 3:32 PM

CMS crash with core files and multiple report output generation

Happy new year to everyone,
Our BOXIR3.1SP6FP2 env has recently started behaving weirdly by triggering multiple output to users inbox and email notification out of scheduled reports. Also we have noticed the CMS crash with core file (almost 4GB) generation at the time of multiple report output.
Most of the times, CMC crashes and recycles itself. At few times, CMS services alone went shut down.
OS details: RHEL 5.5, 32 GB RAM, 8 core processor on each of the clustered node, Oracle 10GR2.4 CMS DB server, 11GR2.4 oracle reporting DB server and oracle 11.1.0.6 client.
2015/01/21 23:54:37.946|>=| | |28123|1534131088|{|||||||||||||||DBQueue::Read
2015/01/21 23:54:37.946|==| | |28123|1496185744|
|||||||||||||||(OracleStatement.cpp:156) Prepare: SQL: SELECT ObjectID,
Version, LastModifyTime, CRC, Properties FROM CMS_InfoObjects6 WHERE ObjectID
IN (1004050) ORDER BY ObjectID
2015/01/21 23:54:37.946|==| | |28123|1496185744| ||||||||||||||(OracleStatement.cpp:183) Prepared statement Execute
2015/01/21 23:54:37.965|==| | |28123|1496451984| |||||||||||||||SResourceSource::LoadString 50293
2015/01/21 23:54:37.966|==| | |28123|1496451984| |||||||||||||||SResourceSource::LoadString Unknown exception in database thread
2015/01/21 23:54:37.967|==| | |28123|1496451984| |||||||||||||||SResourceSource::LoadString 33007
2015/01/21 23:54:37.967|==| | |28123|1496451984| |||||||||||||||SResourceSource::LoadString CMS is unstable and will shut down immediately. Reason: %1...
2015/01/21 23:54:38.506|==| | |28123|1496185744| |||||||||||||||(OracleStatement.cpp:156) Prepare: SQL: SELECT ObjectID,
Version, LastModifyTime, CRC, Properties FROM CMS_InfoObjects6 WHERE ObjectID IN (1009213) ORDER BY ObjectID
2015/01/21 23:54:38.506|==| | |28123|1496185744| |||||||||||||||(OracleStatement.cpp:183) Prepared statement Execute
2015/01/21 23:54:38.512|==| | |28123|1455592672| |||||||||||||||(sidaemon.cpp:549) SUNIXDaemon::run: server restart flag is 1..
2015/01/21 23:54:38.513|==| | |28123|1455592672| |||||||||||||||(sidaemon.cpp:552) SUNIXDaemon::run: in abort ...
2015/01/21 23:54:38.513|==| | |28123|1455592672| |||||||||||||||(sidaemon.cpp:555) SUNIXDaemon::run: doing the WithAbort case ...
2015/01/21 23:54:38.520|==| | |28123|1496185744| |||||||||||||||(dbq.cpp:1357) DBQ: Time required to read 1 objects: 20.000000 ms
Thank you,
Karthik

Hi Denis,
I'm trying my best for the last few weeks to understand the core issue along with SAP however it is still a mystery.
>Ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 270335
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 270335
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
Below is the observation as part of troubleshooting:
1. CMS breaks at threshold of 3.9 G.
2. CMS DB sits in a different Linux server than BOE server.
3. All core files were generated by boe_cmsd process and are almost 4GB in size (same as max threshold which it breaks).
4. Shell script which I've added in the BOE servers shows that the CMS DB is available/connecting at the time of CMS crash.
5. SAP analysed the Core files and skeptical about the below lines.
     #3 0x58687b80 in skgesigCrash ()
      from /opt/oracle/product/11.1.0/client_1/lib32/libclntsh.so
     #4 0x58687e0d in skgesig_sigactionHandler ()
I'll continue troubleshooting with a hope to fix it at the earliest.
Thanks,
Karthik

HT6114 I am unable to attach audio and vido files using mail after I upgraded to mavericks. 10.9.2 2x2.4 Ghz qyad core intel Xeon

Has anyone found a solution for attaching video and audio files in mail with Mavericks. It works fine on my macbook pro but does not work on my desktop. I get the spinning wheel of death. It worked fine before I upgraded to Mavericks.
2x2.4 HGz Quad core Intel Xeon, 12GB 1066 Mhz DDR3.
Thanks
Tom

Has anyone found a solution for attaching video and audio files in mail with Mavericks. It works fine on my macbook pro but does not work on my desktop. I get the spinning wheel of death. It worked fine before I upgraded to Mavericks.
2x2.4 HGz Quad core Intel Xeon, 12GB 1066 Mhz DDR3.
Thanks
Tom

What are Core files and can I delete them?

I need to clean out duplicate and needless files. What are Core.XXXX files and what happens if I delete them?

Here's an update, in case anyone else has this problem: I trashed the files, and no problems whatsoever.

Finding open file handles from core file using mdb/dbx

Is it possible to find open file handles from a core file? The env is Solaris 5.10 SPARC.
regards
becks

Interesting question, but it's more about Solaris OS/libraries than about Sun Studio C++ compiler. While there's a chance of getting it answered here, I also recommend to post the same question on one of the OpenSolaris forums:
http://www.opensolaris.org/jive/index.jspa?categoryID=1
For example, mdb forum:
http://www.opensolaris.org/jive/forum.jspa?forumID=4

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.

Use of DBX and shared libraries with SparcWORKS 5.0

We've been trying without much success to debug customer core files using SparcWORKS 5.0 on Solaris 7. Regardless of what we try (including recommended 'fixes' or 'workarounds' we get this message;
<pre>
core file header read successfully
Reading ld.so.1
dbx: warning: could not initialize librtld_db.so.1 -- trying libDP_rtld_db.so
dbx: panic: cannot dlopen libDP_rtld_db.so as "/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/../../lib/libDP_rtld_db.so" either
-- ld.so.1: /opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx: fatal:
/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/../../lib/libDP_rtld_db.so:
corrupt or truncated file
</pre>
Anyone have any suggestions?

This looks like a known bug 42057057. This bug has been fixed in
Workshop5.0 patch. It is ia fix in Dbx.
WorkShop IPE 5.0: Patch for dbx
Free Patch Descriptions: 107355-07
Please get that patch and install it.
....jagruti

DBX and Core File

Similar Messages

Maybe you are looking for