Dbx: warning

Hi all,
Current I am using Sun Solaris 5.8 and oracle database 9.2.0.2. I am getting following message when running myexe from dbx.
==============================
t@1 (l@1) terminated by signal SEGV (no mapping at the fault address)
0xfe642384: realfree+0x0070: ld [%i0 + 0x8], %o2
Current function is lookup_MFG_AREA_SK
dbx: warning: File `/home/SRC/prod/Solaris8/9.2.0.2/common/sqlutl/LoaderUtils.c' has been modified more recently than `LoaderUtils.o'
===============================
1. I am running my executable from this path `/home/SRC/prod/Solaris8/9.2.0.2/src/`
2. myexe.pc has been build (linked) using
`/home/lib/LoaderUtils.o`
3. Loaderutils.o has been build by "/home/SRC/prod/Solaris8/9.2.0.2/common/sqlutl/LoaderUtils.pc"
Can someone help me. Thanks in advance.
Regards
Ravi

The dbx command "module -v LoaderUtils.o"
should give more information about that
specific module.
(dbx) module -v t.o
Module: t.o
Language: c
Debugging information: read [stabs version: 0.0]
Source file: /home/quenelle/t.c
Object file (original) : /home/quenelle/t.o
Object file (using) : cannot find file (see `help pathmap')
Loadobject: /home/quenelle/a.out
Also, use "ls -la" to check the time stamps on all
the related files to double check if something strange
is going on in your build someplace.

Similar Messages

Unknown dbx warning

Hi all,
can someone explain me, what the reason for the dbx warning: "can't find symbolic information for thrown type (missing N_LSYM/YR stab?)" is. It show up on a Solaris 2.8 machine, when I debug a C++ program.
uname -a
SunOS sun4 5.8 Generic_108528-24 sun4u sparc SUNW,Ultra-80
Thanks in advance
Arno

This message is about missing (or possibly corrupt) debugger information. Which version of dbx and compiler do you use?
Also, it would be of great help if you can post reasonably small testcase for this problem here.
Thanks!

Dbx: internal warning: Unable to get fun table addr in librtc.so

Hi
I am trying to resolve a memory leak in my program.
getting the following errors:
leaks checking - ON
RTC: Enabling Error Checking...
dbx: internal warning: Unable to get fun table addr in librtc.so
dbx: Error checking initialization failed. All error checking disabled.
dbx: warning: Error checking initialization failed.
followed the following steps.
1. setenv LD_PRELOAD /opt/SUNWspro/lib/librtc.so
2. Ran the program. the program forks a child process.
3. Attached to the child process.
4. issued check -leaks, results in following error.
Attached to process 13954
stopped in _read at 0xfeb9e880
0xfeb9e880: _read+0x0008: ta 0x8
dbx: internal warning: set_error_limit called too early
(dbx) check -leaks
leaks checking - ON
RTC: Enabling Error Checking...
dbx: internal warning: Unable to get fun table addr in librtc.so
dbx: Error checking initialization failed. All error checking disabled.
dbx: warning: Error checking initialization failed.
(dbx)
dbx version:
Sun Dbx Debugger 7.1 Patch 112758-02 2003/11/12
System Info
Operating System: SunOS Release 5.8 Generic_117350-04
Type:SUNW, UltraAX-i2; sparc; sun4u
Any hints welcome.
Thanks
Bhaskar Mathur

Replied
Rose

Issue in enabling dbx rtc for memory leak analysis

Any help on this is highly appreciated ...
Following is the issue:
pass@odcsmoke1> dbx -C xfer
changes (topic)
The major new features of this release relative to 6.1 are:
o The dbx environment variable "rtc_use_traps" has been removed.
Traps are used automatically as long as the hardware is UltraSparc.
o There is now some basic support for looking at core files from
different versions of Solaris. See `help core mismatch' for details.
o Stepping to a specific function support. See `help step to' for details.
o Fortran intrinsics support on Intel has been removed.
o Dbx automatically translates some old dbxenv variables to their new
names. See `help dbxenv' for details.
o The default command-line editing mode is now emacs. See "How do I enable
command-line editing?" in FAQ for details (`help FAQ').
o Two new collector commands have been implemented: `pause' and `resume'.
See `help collector' for details.
o The collector enable_once command has been removed.
o The collector store command has been extended to include experiment groups.
See also `help changes61'
To suppress this message, add the following line to your .dbxrc file:
dbxenv suppress_startup_message 6.2
Reading xfer
Reading ld.so.1
Reading librtc.so
Reading libm.so.1
Reading libnsl.so.1
Reading libresolv.so.2
Reading libc.so.1
Reading libgen.so.1
Reading libdl.so.1
Reading librt.so.1
Reading libpthread.so.1
Reading libthread.so.1
Reading libsocket.so.1
Reading libxfermain.so
Reading libpass.so
Reading libarsapic.so
Reading libarsrecordc.so
Reading libiaconfig.so
Reading libarsconfig.so
Reading libclientsock.so
Reading libaio.so.1
Reading libmd5.so.1
detected a multithreaded program
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) check -all
access checking - ON
memuse checking - ON
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) check -leaks
leaks checking - ON
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) stop in main
More than one identifier 'main'.
Select one of the following:
0) Cancel
1) `xfer`xfer.c`main
2) `libxfermain.so`xfer.c`main
a) All
1(2) stop in main
-d ecpix.conf -g y -P n <
Running: xfer -f rbi_1.cfg -d ecpix.conf -g y -P n
(process id 33)
dbx: warning: A threaded program is not initializing libthread first!
*/opt/SUNWspro/WS6U2/lib/dbxruntime/librtc.so came before it.*
dbx: warning: A threaded program is not initializing libthread first!
/lib/libc.so.1 came before it.
dbx: warning: A threaded program is not initializing libthread first!
/lib/libnsl.so.1 came before it.
dbx: warning: A threaded program is not initializing libthread first!
/lib/libsocket.so.1 came before it.
dbx: warning: A threaded program is not initializing libthread first!
/lib/libresolv.so.2 came before it.
dbx: warning: A threaded program is not initializing libthread first!
/lib/libgen.so.1 came before it.
dbx: warning: A threaded program is not initializing libthread first!
/lib/libaio.so.1 came before it.
dbx: warning: A threaded program is not initializing libthread first!
/lib/libmd5.so.1 came before it.
dbx: warning: A threaded program is not initializing libthread first!
/lib/librt.so.1 came before it.
dbx: warning: A threaded program is not initializing libthread first!
/usr/pass/lib/sparc-sun-solaris2.8/libpass.so came before it.
dbx: warning: A threaded program is not initializing libthread first!
/usr/pass/lib/sparc-sun-solaris2.8/libclientsock.so came before it.
dbx: warning: A threaded program is not initializing libthread first!
/usr/pass/lib/sparc-sun-solaris2.8/libarsrecordc.so came before it.
dbx: warning: A threaded program is not initializing libthread first!
/usr/pass/lib/sparc-sun-solaris2.8/libiaconfig.so came before it.
dbx: warning: A threaded program is not initializing libthread first!
/usr/pass/lib/sparc-sun-solaris2.8/libarsapic.so came before it.
dbx: warning: A threaded program is not initializing libthread first!
/usr/pass/lib/sparc-sun-solaris2.8/libarsconfig.so came before it.
dbx: warning: A threaded program is not initializing libthread first!
/usr/pass/lib/sparc-sun-solaris2.8/libxfermain.so came before it.
dbx: warning: A threaded program is not initializing libthread first!
/usr/pass/etc/xfer came before it.
stopped in main at line 461 in file "xfer.c"
461 CHAR *Etc_Dir="/usr/pass/etc/";
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) showmemuse
dbx: warning: check -leaks/-memuse must be issued before the run command for showmemuse to be used(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx)
pass@odcsmoke1> uname -a
SunOS odcsmoke1 5.10 Generic_118822-30 sun4u sparc SUNW,Sun-Fire-V250

Andrew is right, dbx 6.2 is very old; technically, it is supported on Solaris 10, but as you can see for yourself, there are issues to be fixed.
Only limited support is available for this version, so if you have a support contract, please report this problem through the support channel. Better yet (and in case if you don't have support contract), upgrade to a more modern version. Since you are on Solaris 10, I'd recommend latest version of Sun Studio - 12 update 1; it is free for all uses and can be downloaded from here: http://developers.sun.com/sunstudio/downloads/.
Should you have any questions about the upgrade, please post it here.

Studio 12 DBX internal error while memcheck is on.

bash-3.00$ dbx -xexec32
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
(dbx) -rwxr-xr-x 1 orbit osgrp1 1.2M Dec 26 17:18 <my_processnmae>
-rwxr-xr-x: not found
(dbx) dbxenv mt_sync_tracking off
(dbx) attach 6792 <this is pid>
Reading <my_processname>
Reading ld.so.1
Reading librtc.so
Reading libmapmalloc.so.1
Reading libcurses.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libelf.so.1
Reading libcrypt_i.so.1
Reading libpthread.so.1
Reading libdl.so.1
Reading librt.so.1
Reading libc.so.1
Reading libgen.so.1
Reading libaio.so.1
Reading libmd5.so.1
Reading libc_psr.so.1
Reading library_name**
Reading library_name**
Attached to process 6792 with 3 LWPs
t@1 (l@1) stopped in soaccept at 0xff040314
0xff040314: soaccept+0x0004: ta %icc,0x00000008
Current function is Tcp_receive
284 if ((th_data->sockfd = accept (sockfd, (struct sockaddr *)&clientaddr,&length)) == -1)
(dbx) check -access
access checking - ON
RTC: Enabling Error Checking...
RTC: Running program...
(dbx) cont
RTC: internal RTC error -- disabling Error Checking file: rtc_heap_map.c line: 697
^Ct@2 (l@2) signal INT (Interrupt) in ___sigtimedwait at 0xff040220
0xff040220: ___sigtimedwait+0x0004: ta %icc,0x00000008
Current function is sig_thr
1256 sigwait (&glb_sigact, &signal_alr);
(dbx) version
Machine hardware: sun4u
OS version: 5.10
Processor type: sparc
Hardware: SUNW,Sun-Fire-280R
The following components are installed on your system:
Sun Studio 12
Sun Studio 12 C Compiler
Sun Studio 12 C++ Compiler
Sun Studio 12 Tools.h++ 7.1
Sun Studio 12 C++ Standard 64-bit Class Library
Sun Studio 12 Garbage Collector
Sun Studio 12 Fortran 95
Sun Studio 12 Debugging Tools (including dbx)
Sun Studio 12 IDE
Sun Studio 12 Debugger GUI
Sun Studio 12 Performance Analyzer (including collect, ...)
Sun Studio 12 X-Designer
Sun Studio 12 VIM editor
Sun Studio 12 XEmacs editor
Sun Studio 12 Performance Library
Sun Studio 12 LockLint
Sun Studio 12 Building Software (including dmake)
Sun Studio 12 Documentation Set
Sun Studio 12 /usr symbolic links and GNOME menu item
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9 SunOS_sparc 2007/05/03
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9 SunOS_sparc 2007/05/03
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95 8.3 SunOS_sparc 2007/05/03
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx Debugger 7.6 SunOS_sparc 2007/05/03
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun Analyzer 7.6 SunOS_sparc 2007/05/03
version of "/opt/SunStudio12/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun Distributed Make 7.8 SunOS_sparc 2007/05/03
any Idea ?
am i doing something wrong here. ? I want to check memory leak. ?
-Raxit

With hope if its bug, below may helpful.
(dbx) (dbx) (dbx) quit
detaching from process 6792
dbx: internal warning: function (__rtc_release_heap_region) called too early (preloading)
t@3 (l@3) signal SEGV (no mapping at the fault address) in _sleep at 0xff0330f0
0xff0330f0: _sleep+0x0078: ldsb [%o3 - 3005], %o2
Current function is scansessionisam_thr
1362 sleep (cfg_sec_shm_scantime); /*SCF no 10750 */
execution completed, exit code is 4982056
dbx: internal warning: rtc: _syscall: failed
dbx: warning: librtc.so and dbx version mismatch; Error checking disabled
Check your installation of librtc.so.
dbx: internal warning: rtc: munmap of patch area of segment '/usr/lib/libmapmalloc.so.1' failed
dbx: internal error: signal SIGSEGV (no mapping at the fault address)
dbx's coredump will appear in /tmp
ls -lrAbort (core dumped)
bash-3.00$ pstack /tmp/core
core '/tmp/core' of 6794: dbx -xexec32
ff1c0f90 lwpkill (6, 0, ff1a4a98, ffffffff, ff1e8284, 6) + 8
ff13ff98 abort (0, 1, 377d74, a83f0, ff1eb298, 0) + 110
000b5bf8 ???????? (b, 3c4400, 4575a1, 38b1f4, 37eabe, 1)
ff1bfec8 __sighndlr (b, ffbff408, ffbff150, b59ec, 0, 1) + c
ff1b4ff4 call_user_handler (b, 0, 8, 0, ff252000, ffbff150) + 3b8
001aef98 __1cGRtcMgrShandle_proc_detach6M_v_ (47d670, 5dd2a8, 38, 396000, 4c0498, 38) + d8
0018f850 __1cEProcGdetach6Mbbbb_v_ (4c0468, 467400, 466400, 0, 3ae2ac, 0) + 19c
000b8c68 ???????? (47e6f8, 0, 0, 0, 0, 1)
00289d94 __1cMpdksh_c_exit6FpnGInterp_ippcpv_i_ (47e6f8, 0, 876890, 0, 0, 466000) + a8
0015fbf4 ???????? (47e6f8, 1, 876890, 0, 877b78, 0)
002857a0 ???????? (47e6f8, 877b78, 877b58, 876890, 0, 467708)
0028468c __1cNpdksh_execute6FpnGInterp_pnCop_i_i_ (47e6f8, 49bab8, 0, 277c50, 47e6f8, 38b1f4) + 194
002735e0 __1cLpdksh_shell6FpnGInterp_pnGSource__i_ (47e6f8, 49e098, 465628, 446f54, 3d9625, 3d962c) + 46c
000b90d4 __1cNmain_cmd_loop6FpnGInterp__v_ (47e6f8, 37f400, 3ca2a4, 446f70, 3ca000, 3ca000) + 88
000b9e60 main (37e400, 0, 40, 47e6f8, 37f7c8, 1) + 750
000af268 _start (0, 0, 0, 0, 0, 0) + 108
bash-3.00$
bash-3.00$ dbx /opt/SunStudio12/
SUNWspro/ uninstall_Sun_Studio_12.class
bash-3.00$ dbx /opt/SunStudio12/SUNWspro/bin/dbx /tmp/core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
Reading dbx
core file header read successfully
Reading ld.so.1
Reading libintl.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libdl.so.1
Reading libgen.so.1
Reading libw.so.1
Reading libm.so.1
Reading libc.so.1
Reading libc_psr.so.1
Reading libcpc.so.1
Reading libpctx.so.1
Reading libnvpair.so.1
Reading libdevinfo.so.1
Reading libproc.so.1
Reading librtld_db.so.1
Reading libelf.so.1
Reading libctf.so.1
program terminated by signal ABRT (Abort)
0xff1c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xff1c0fa0
(dbx) threads
dbx: thread related commands not available
(dbx) where
=>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xff1c0f90
[2] raise(0x6, 0x0, 0xff1a4a98, 0xffffffff, 0xff1e8284, 0x6), at 0xff15fd78
[3] abort(0x0, 0x1, 0x377d74, 0xa83f0, 0xff1eb298, 0x0), at 0xff13ff98
[4] 0xb5bf8(0xb, 0x3c4400, 0x4575a1, 0x38b1f4, 0x37eabe, 0x1), at 0xb5bf8
[5] __sighndlr(0xb, 0xffbff408, 0xffbff150, 0xb59ec, 0x0, 0x1), at 0xff1bfec8
---- called from signal handler with signal 11 (SIGSEGV) ------
[6] RtcMgr::handle_proc_detach(0x47d670, 0x5dd2a8, 0x38, 0x396000, 0x4c0498, 0x38), at 0x1aef98
[7] Proc::detach(0x4c0468, 0x467400, 0x466400, 0x0, 0x3ae2ac, 0x0), at 0x18f850
[8] 0xb8c68(0x47e6f8, 0x0, 0x0, 0x0, 0x0, 0x1), at 0xb8c68
[9] pdksh_c_exit(0x47e6f8, 0x0, 0x876890, 0x0, 0x0, 0x466000), at 0x289d94
[10] 0x15fbf4(0x47e6f8, 0x1, 0x876890, 0x0, 0x877b78, 0x0), at 0x15fbf4
[11] 0x2857a0(0x47e6f8, 0x877b78, 0x877b58, 0x876890, 0x0, 0x467708), at 0x2857a0
[12] pdksh_execute(0x47e6f8, 0x49bab8, 0x0, 0x277c50, 0x47e6f8, 0x38b1f4), at 0x28468c
[13] pdksh_shell(0x47e6f8, 0x49e098, 0x465628, 0x446f54, 0x3d9625, 0x3d962c), at 0x2735e0
[14] main_cmd_loop(0x47e6f8, 0x37f400, 0x3ca2a4, 0x446f70, 0x3ca000, 0x3ca000), at 0xb90d4
[15] main(0x37e400, 0x0, 0x40, 0x47e6f8, 0x37f7c8, 0x1), at 0xb9e60
(dbx)
-Raxit

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

How can i copy a dbx executable to other machine to run without installion

How can i copy a dbx executable to other machine to run without installion whole workshop
packet??? how to generate a configuration for dbx alone???
thanks

Hi, thanks for you help.
actually, I have once copied dbx to other machine. certainlly, it needs a license. But when I copied
a license file from the directory /opt/SUNWspro/license-dir/ of machine that installed Workshop
to another machine that i want to run dbx. dbx starts correctly. but when i type
$ dbx ipCentrex
it prints following message:
dbx: warning: cannot find global initialization file: dbxrc
/opt/wacos/./.dbxrc[1]: syntax error
dbx: installation problem, can't find help file: ./SUNW_SPRO_Dbx_help.info
_find_executable: not found
To suppress this message, add the following line to your .dbxrc file:
dbxenv suppress_startup_message 6.2
Reading ipCentrex
dbx: warning: setuid program exec()ed. Reattaching
There might be too many LWP's in this process.
See `help dbxenv' under mt_scalable.
dbx: Cannot open lwpstatus.
dbx: warning: process initialization failed
dbx: warning: can't find file "/opt/wacos/server/feature_server/bin/obj/ipCentre
x/ipcentrex_main.o"
dbx: warning: see `help finding-files'
when it says that has errors in .dbxrc file, I can remove this file. But the critical error is why it says
too mamy LWP's in this process? when I debug it at a machine that installed workshop, this error not occurs.
anyone have answer?

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 - different date and time compilation

Hello,
I am trying to open a core file but I did not have some .o files linked in the executable. Therefore I compiled them and tried to open the core file. I got this warning:
Object file:
(...)ss_sm/server/src/gsadminserverinterface.o
compiled on: Fri Dec 2 09:25:40 2005
Executable contains object file compiled on: Tue Feb 1 11:08:18 2005
and when I tried to use the "where" and "list" commands the result was:
(/opt/SUNWspro/bin//../WS6U2/bin/sparcv9/dbx) where
current thread: t@104
=>[1] GS_AdminServerInterface::getAllConfiguredDomains(0xf6efbf90, 0xf6efbf50, 0xf8d4ef5b, 0xf8d4ef72, 0xfdb8d318, 0x0), at 0xf8cf0888
[2] GS_SecDataInitializeController::getDataFromAdminServer(0x0, 0xf8d0edd0, 0x0, 0x0, 0x0, 0x0), at 0xf8d0ef84
(/opt/SUNWspro/bin//../WS6U2/bin/sparcv9/dbx) list
dbx: warning: No source file
Is there a way to skip the check of the date and time of compilation? The code is the same but the compile time is different.
Thanks.
I am using:
-SunOS ol133 5.9 Generic_117171-13 sun4u sparc SUNW,Sun-Fire-V210
-dbx 6.2

One problem is that some debugging information (stabs and dwarf)
is left in the .o files, and not copied into the a.out.
This problem will go away when we move from stabs to dwarf.
Here is more information about lazy stabs.
http://blogs.sun.com/roller/page/quenelle?entry=the_story_of_lazy_stabs
It might be useful to have an option to "force" dbx to read
stabs from a .o file that is not the same as the one in the a.out,
but I don't think we have that option yet. It won't be needed
after we move to dwarf.
Read more about dwarf here:
http://blogs.sun.com/roller/page/quenelle?entry=stabs_versus_dwarf

Studio 12: dbx: internal error: signal SIGSEGV (no mapping at the fault add

$dbx /usr/bin/dbx /tmp/core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
Reading dbx
core file header read successfully
Reading ld.so.1
Reading libintl.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libdl.so.1
Reading libgen.so.1
Reading libw.so.1
Reading libm.so.1
Reading libc.so.1
Reading libc_psr.so.1
Reading en_US.UTF-8.so.3
Reading methods_unicode.so.3
Reading iso_8859_1.so.3
Reading libcpc.so.1
Reading libpctx.so.1
Reading libnvpair.so.1
Reading libdevinfo.so.1
Reading libproc.so.1
Reading libsec.so.1
Reading librtld_db.so.1
Reading libelf.so.1
Reading libctf.so.1
Reading libavl.so.1
Reading libc_db.so.1
Reading ld.so.1
WARNING!!
A loadobject was found with an unexpected checksum value.
See `help core mismatch' for details, and run `proc -map'
to see what checksum values were expected and found.
dbx: warning: Some symbolic information might be incorrect.
program terminated by signal ABRT (Abort)
0xffffffff7e5ce968: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7e5ce978
(dbx) where
=>[1] __lwp_kill(0x0, 0x6, 0x0, 0xffffffff7e6f1200, 0xffffffff7e902000, 0x5), at 0xffffffff7e5ce968
[2] raise(0x6, 0x0, 0xffffffff7e5b11b8, 0xffffffffffffffff, 0xffffffff7e6e6000, 0x0), at 0xffffffff7e56b454
[3] abort(0x1, 0x1b8, 0x0, 0x19d4c0, 0x0, 0x0), at 0xffffffff7e548c4c
[4] 0x1000bfd0c(0xb, 0x100400, 0x1, 0x1005104ec, 0x10051d110, 0x10061c000), at 0x1000bfd0c
[5] __sighndlr(0xb, 0xffffffff7fffae80, 0xffffffff7fffaba0, 0x1000bfa9c, 0x0, 0xa), at 0xffffffff7e5cd86c
---- called from signal handler with signal 11 (SIGSEGV) ------
[6] strcmp(0x0, 0x10acaba20, 0xfffffffef53545e0, 0x0, 0x8080808080808080, 0x101010101010101), at 0xffffffff7e53952c
[7] 0x10016804c(0x10d2ad310, 0x0, 0x1066ec6b0, 0x10acab980, 0x0, 0x1066ec6b0), at 0x10016804c
[8] 0x1001682f8(0x0, 0x0, 0x0, 0xfffffffff586e366, 0x0, 0x0), at 0x1001682f8
[9] 0x1000d3d68(0x103f561a0, 0x10e88bac0, 0x10aefe1c0, 0x10668f7d0, 0x0, 0x0), at 0x1000d3d68
[10] 0x1000d4f08(0x103f561a0, 0x10e88bac0, 0x10aefe1c0, 0x10668f7d0, 0x0, 0x0), at 0x1000d4f08
[11] 0x1000d44d4(0x1027c8b80, 0x10e88bac0, 0x10aefe1c0, 0x10668f7d0, 0x0, 0x0), at 0x1000d44d4
[12] 0x1000d4504(0x107721b00, 0x10e88bac0, 0x10aefe1c0, 0x10668f7d0, 0x0, 0x0), at 0x1000d4504
[13] 0x1000d44d4(0x107721a70, 0x10e88bac0, 0x10aefe1c0, 0x10668f7d0, 0x0, 0x0), at 0x1000d44d4
[14] 0x1000d44d4(0x10668f7d0, 0x10e88bac0, 0x10aefe1c0, 0x10668f7d0, 0x0, 0x0), at 0x1000d44d4
[15] 0x100273900(0x0, 0x10668f7d0, 0x10e88bac0, 0x10aefe1c0, 0x10668f7d0, 0x0), at 0x100273900
[16] 0x10027c8c0(0x4, 0x10668f7d0, 0x10e88bac0, 0x10aefe1c0, 0x10668f7d0, 0x0), at 0x10027c8c0
[17] 0x10013c280(0x0, 0x10aecd060, 0x10e88bac0, 0x10aefe1c0, 0x10668f7d0, 0x0), at 0x10013c280
[18] 0x10013d390(0xffffffff7fffd198, 0x10052adb8, 0xffffffff7fffd30f, 0x10f120de0, 0x10f120dc0, 0x10061c470), at 0x10013d390
[19] 0x1001b1fe4(0x1023f00e0, 0x100400, 0x10051d110, 0x10051d000, 0x100547000, 0x100547), at 0x1001b1fe4
[20] 0x1000cc988(0x10c128730, 0x10061a, 0x10061a000, 0x1027eafa0, 0x0, 0x328), at 0x1000cc988
[21] 0x1000ca47c(0x1066ec770, 0x10ff2c500, 0x10ff2c500, 0x1027eafa0, 0x1, 0x0), at 0x1000ca47c
[22] 0x10016dec0(0x10ff2c500, 0x1066c1f50, 0xc03, 0x100400, 0x100537509, 0x1027eafa0), at 0x10016dec0
[23] 0x1001cae20(0x10ff2c500, 0x1066c1f50, 0x100400, 0x100537950, 0x100569bb8, 0x100569), at 0x1001cae20
[24] 0x1001cb3d0(0x10051d110, 0x1066c1f50, 0x1001ca098, 0x1, 0x0, 0x100631590), at 0x1001cb3d0
[25] 0x1001bc948(0x1066c1f50, 0x10ac5dbf0, 0x1005248b8, 0x100224a28, 0x10a778a38, 0x100628e00), at 0x1001bc948
[26] 0x1001bcae8(0x1066c1f50, 0x100563818, 0x100563818, 0x1002247b8, 0x100549300, 0x100563898), at 0x1001bcae8
[27] 0x1001bd294(0x1066c1f50, 0x1005638a0, 0x100400, 0x10c905fd0, 0x100549493, 0x100569cf8), at 0x1001bd294
[28] 0x1001bd934(0x1066c1f50, 0x1005638a0, 0x0, 0x0, 0x106e1c998, 0x10054963b), at 0x1001bd934
[29] 0x1001873b4(0x10051d110, 0x1005638a0, 0x0, 0x10020fd68, 0x1005618e8, 0x100400), at 0x1001873b4
[30] 0x100187b34(0x10051d110, 0x0, 0x100611000, 0x0, 0x0, 0x100621f60), at 0x100187b34
[31] 0x1001884b4(0x102592150, 0x2, 0x102592172, 0x1066ed0a0, 0x1, 0x10051d110), at 0x1001884b4
[32] 0x1002cc4d8(0x100648bb0, 0x400, 0x1027e98c0, 0x1066ed0a0, 0x0, 0x10061cfc0), at 0x1002cc4d8
[33] 0x1002cb2f0(0x0, 0x10699e080, 0x0, 0x100648bb0, 0x1002cb0e0, 0x1005365f8), at 0x1002cb2f0
[34] 0x1002b8494(0x100648bb0, 0x1067d0b40, 0x10061a778, 0x1005f7578, 0x10057a289, 0x10057a290), at 0x1002b8494
[35] 0x1002b7ef0(0x100648bb0, 0x10805db04, 0x0, 0x1, 0x100400, 0x1006ae570), at 0x1002b7ef0
[36] 0x100161460(0x10067aef0, 0x0, 0x0, 0x10805db04, 0x100535000, 0x10061ceb8), at 0x100161460
[37] 0x1002fa654(0x1002e2020, 0x1002e2020, 0xffffffff7fffe1f8, 0x7fc00, 0x100585688, 0x0), at 0x1002fa654
[38] 0x1002f6880(0x10067aef0, 0x0, 0xffffffff7fffe1f8, 0x1, 0x20ef7c, 0x1005365f8), at 0x1002f6880
[39] 0x1002f6584(0x10067aef0, 0x0, 0x7ec00, 0x20f290, 0x0, 0x100584384), at 0x1002f6584
[40] 0x1002e99f0(0xb, 0x7b7f3, 0x10067aef0, 0x21bdec, 0x100505748, 0x7b400), at 0x1002e99f0
[41] 0x1002e4c28(0x10063a900, 0xb, 0x1, 0x220bc4, 0x100505748, 0x10057f594), at 0x1002e4c28
[42] 0x1002e50dc(0x10067a1b0, 0xb, 0x1, 0x1002e4b80, 0x0, 0x100580008), at 0x1002e50dc
[43] 0x1002e5a20(0x10067a1b0, 0xb, 0x1, 0x10063a900, 0xffffffff7fffe9af, 0x1), at 0x1002e5a20
[44] 0x1002e6084(0x10067a1b0, 0xffffffff7fffe9af, 0xffffffff7fffe5b0, 0xffffffff7fffe5d0, 0xffffffff7fffe6f0, 0x3), at 0x1002e6084
[45] 0x1002e5bac(0x10067a1b0, 0xffffffff7fffe9af, 0x7f258, 0x1, 0x100505748, 0x10057fa69), at 0x1002e5bac
[46] 0x10015ed40(0x100648bb0, 0xffffffff7fffeabc, 0x100400, 0x100535a8f, 0x10051d110, 0x100535), at 0x10015ed40
[47] 0x1002bf754(0x100648bb0, 0x10061c468, 0x10057ad5e, 0x0, 0x1006ae570, 0x100648bce), at 0x1002bf754
[48] 0x1002bd828(0x100648bb0, 0xc, 0x0, 0x0, 0xffffffff7fffec4c, 0x100648df0), at 0x1002bd828
[49] 0x1002bb3b8(0x100648bb0, 0x100400, 0xffffffff7fffedc8, 0x10057ce29, 0x16, 0x1), at 0x1002bb3b8
[50] 0x1002bd4a4(0x100648bb0, 0x1006ae570, 0x0, 0x45, 0x100648d58, 0x1006ae5f8), at 0x1002bd4a4
[51] 0x1002b82c0(0x100648bb0, 0x1006ae570, 0x10061a778, 0x1005f7578, 0x10057a289, 0x10057a290), at 0x1002b82c0
[52] 0x1000c3b80(0x100648bb0, 0x10065df30, 0x1005f7590, 0x100569c20, 0x1005111a8, 0x0), at 0x1000c3b80
[53] 0x1000c4964(0x100400, 0x100510, 0x100648bb0, 0x1005111a8, 0x202, 0x1), at 0x1000c4964

$dbx - /tmp/core
Corefile specified executable: "/opt/SUNWspro/prod/bin/sparcv9/dbx"
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
Reading dbx
core file header read successfully
Reading ld.so.1
Reading libintl.so.1
Reading libnsl.so.1
Reading libsocket.so.1
Reading libdl.so.1
Reading libgen.so.1
Reading libw.so.1
Reading libm.so.1
Reading libc.so.1
Reading libc_psr.so.1
Reading en_US.UTF-8.so.3
Reading methods_unicode.so.3
Reading iso_8859_1.so.3
Reading libcpc.so.1
Reading libpctx.so.1
Reading libnvpair.so.1
Reading libdevinfo.so.1
Reading libproc.so.1
Reading libsec.so.1
Reading librtld_db.so.1
Reading libelf.so.1
Reading libctf.so.1
Reading libavl.so.1
Reading libc_db.so.1
program terminated by signal ABRT (Abort)
0xffffffff7e5ce968: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7e5ce978
(dbx) where
=>[1] __lwp_kill(0x0, 0x6, 0x0, 0xffffffff7e6f1200, 0xffffffff7e902000, 0x5), at 0xffffffff7e5ce968
[2] raise(0x6, 0x0, 0xffffffff7e5b11b8, 0xffffffffffffffff, 0xffffffff7e6e6000, 0x0), at 0xffffffff7e56b454
[3] abort(0x1, 0x1b8, 0x0, 0x19d4c0, 0x0, 0x0), at 0xffffffff7e548c4c
[4] 0x1000bfd0c(0xb, 0x100400, 0x1, 0x1005104ec, 0x10051d110, 0x10061c000), at 0x1000bfd0c
[5] __sighndlr(0xb, 0xffffffff7fffae80, 0xffffffff7fffaba0, 0x1000bfa9c, 0x0, 0xa), at 0xffffffff7e5cd86c
---- called from signal handler with signal 11 (SIGSEGV) ------
[6] strcmp(0x0, 0x1073a0640, 0xfffffffef8c5f9c0, 0x0, 0x8080808080808080, 0x101010101010101), at 0xffffffff7e53952c
[7] VisitedFunc::contains(0x106d71f00, 0x0, 0x106d71d50, 0x106d0b010, 0x0, 0x106d71d50), at 0x10016804c
[8] VisitedFunc::is_open(0x0, 0x0, 0x0, 0xfffffffffb7b11e6, 0x0, 0x0), at 0x1001682f8
[9] 0x1000d3d68(0x103f561a0, 0x107488f00, 0x1027fb180, 0x102592350, 0x0, 0x0), at 0x1000d3d68
[10] cc_printval(0x103f561a0, 0x107488f00, 0x1027fb180, 0x102592350, 0x0, 0x0), at 0x1000d4f08
[11] cc_printval(0x1027c8b80, 0x107488f00, 0x1027fb180, 0x102592350, 0x0, 0x0), at 0x1000d44d4
[12] cc_printval(0x107721b00, 0x107488f00, 0x1027fb180, 0x102592350, 0x0, 0x0), at 0x1000d4504
[13] cc_printval(0x107721a70, 0x107488f00, 0x1027fb180, 0x102592350, 0x0, 0x0), at 0x1000d44d4
[14] cc_printval(0x102592350, 0x107488f00, 0x1027fb180, 0x102592350, 0x0, 0x0), at 0x1000d44d4
[15] LanguageC_like::printval(0x0, 0x102592350, 0x107488f00, 0x1027fb180, 0x102592350, 0x0), at 0x100273900
[16] printval(0x4, 0x102592350, 0x107488f00, 0x1027fb180, 0x102592350, 0x0), at 0x10027c8c0
[17] 0x10013c280(0x0, 0x10737fec0, 0x107488f00, 0x1027fb180, 0x102592350, 0x0), at 0x10013c280
[18] Expr::format(0xffffffff7fffd198, 0x10052adb8, 0xffffffff7fffd30f, 0x106d0b450, 0x106d0b0b0, 0x10061c470), at 0x10013d390
[19] printrtn(0x1023f00e0, 0x100400, 0x10051d110, 0x10051d000, 0x100547000, 0x100547), at 0x1001b1fe4
[20] 0x1000cc988(0x107488fb0, 0x10061a, 0x10061a000, 0x106dcabb0, 0x0, 0x328), at 0x1000cc988
[21] ActionList_execute(0x10665f550, 0x106cc71f0, 0x106cc71f0, 0x106dcabb0, 0x1, 0x0), at 0x1000ca47c
[22] Handler::decision_procedure(0x106cc71f0, 0x1006c65c0, 0xc03, 0x100400, 0x100537509, 0x106dcabb0), at 0x10016dec0
[23] Recognizer::trigger(0x106cc71f0, 0x1006c65c0, 0x100400, 0x100537950, 0x100569bb8, 0x100569), at 0x1001cae20
[24] Recognizer::dispatch(0x10051d110, 0x1006c65c0, 0x1001ca098, 0x1, 0x0, 0x100631590), at 0x1001cb3d0
[25] Proc::vcpu_dispatch(0x1006c65c0, 0x1028360e0, 0x1005248b8, 0x100224a28, 0x106644238, 0x100628e00), at 0x1001bc948
[26] Proc::pervcpu_dispatch(0x1006c65c0, 0x100563818, 0x100563818, 0x1002247b8, 0x100549300, 0x100563898), at 0x1001bcae8
[27] Proc::generic_dispatch(0x1006c65c0, 0x1005638a0, 0x100400, 0x1027f1b00, 0x100549493, 0x100569cf8), at 0x1001bd294
[28] Proc::go(0x1006c65c0, 0x1005638a0, 0x0, 0x0, 0x10732dc08, 0x10054963b), at 0x1001bd934
[29] 0x1001873b4(0x10051d110, 0x1005638a0, 0x0, 0x10020fd68, 0x1005618e8, 0x100400), at 0x1001873b4
[30] 0x100187b34(0x10051d110, 0x0, 0x100611000, 0x0, 0x0, 0x100621f60), at 0x100187b34
[31] DbxStepCmdProcessing::process(0x1066e2150, 0x2, 0x1066e2172, 0x10737fd50, 0x1, 0x10051d110), at 0x1001884b4
[32] 0x1002cc4d8(0x100648bb0, 0x400, 0x106dcaa50, 0x10737fd50, 0x0, 0x10061cfc0), at 0x1002cc4d8
[33] pdksh_execute(0x0, 0x1073bae30, 0x0, 0x100648bb0, 0x1002cb0e0, 0x1005365f8), at 0x1002cb2f0
[34] pdksh_shell(0x100648bb0, 0x1075500a0, 0x10061a778, 0x1005f7578, 0x10057a289, 0x10057a290), at 0x1002b8494
[35] pdksh_command(0x100648bb0, 0x107431a44, 0x0, 0x1, 0x100400, 0x1006ae570), at 0x1002b7ef0
[36] MyServantDbx::ksh_cmd(0x10067aef0, 0x0, 0x0, 0x107431a44, 0x100535000, 0x10061ceb8), at 0x100161460
[37] Dispatcher::dispatch(0x1002e2020, 0x1002e2020, 0xffffffff7fffe1f8, 0x7fc00, 0x100585688, 0x0), at 0x1002fa654
[38] Messenger::handle_message_help(0x10067aef0, 0x0, 0xffffffff7fffe1f8, 0x1, 0x20ef7c, 0x1005365f8), at 0x1002f6880
[39] Messenger::handle_message(0x10067aef0, 0x0, 0x7ec00, 0x20f290, 0x0, 0x100584384), at 0x1002f6584
[40] Servant::cb_message(0xb, 0x7b7f3, 0x10067aef0, 0x21bdec, 0x100505748, 0x7b400), at 0x1002e99f0
[41] CBInfo::dispatch(0x10063a900, 0xb, 0x1, 0x220bc4, 0x100505748, 0x10057f594), at 0x1002e4c28
[42] Notifier::invoke(0x10067a1b0, 0xb, 0x1, 0x1002e4b80, 0x0, 0x100580008), at 0x1002e50dc
[43] NotifierDirect::dispatch_help(0x10067a1b0, 0xb, 0x1, 0x10063a900, 0xffffffff7fffe9af, 0x1), at 0x1002e5a20
[44] NotifierPoll::dispatch(0x10067a1b0, 0xffffffff7fffe9af, 0xffffffff7fffe5b0, 0xffffffff7fffe5d0, 0xffffffff7fffe6f0, 0x3), at 0x1002e6084
[45] NotifierDirect::loop(0x10067a1b0, 0xffffffff7fffe9af, 0x7f258, 0x1, 0x100505748, 0x10057fa69), at 0x1002e5bac
[46] 0x10015ed40(0x100648bb0, 0xffffffff7fffeabc, 0x100400, 0x100535a8f, 0x10051d110, 0x100535), at 0x10015ed40
[47] 0x1002bf754(0x100648bb0, 0x10061c468, 0x10057ad5e, 0x0, 0x1006ae570, 0x100648bce), at 0x1002bf754
[48] yylex(0x100648bb0, 0xc, 0x0, 0x0, 0xffffffff7fffec4c, 0x100648df0), at 0x1002bd828
[49] yyparse(0x100648bb0, 0x100400, 0xffffffff7fffedc8, 0x10057ce29, 0x0, 0x1), at 0x1002bb3b8
[50] compile(0x100648bb0, 0x1006ae570, 0x0, 0x5f63625f70726f6d, 0x100648d58, 0x1006ae5f8), at 0x1002bd4a4
[51] pdksh_shell(0x100648bb0, 0x1006ae570, 0x10061a778, 0x1005f7578, 0x10057a289, 0x10057a290), at 0x1002b82c0
[52] main_cmd_loop(0x100648bb0, 0x10065df30, 0x1005f7590, 0x100569c20, 0x1005111a8, 0x0), at 0x1000c3b80
[53] main(0x100400, 0x100510, 0x100648bb0, 0x1005111a8, 0x202, 0x1), at 0x1000c4964

Dbx core dumping

dbx core dumping when I debug my application with RTC enable (I'm truying to dectect some memory leaks in my code). and I'm getting the following
RTC: Enabling Error Checking...
RTC: Running program...
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) suppress rui
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) cont
t@10 (l@10) signal SEGV (no mapping at the fault address) in __rtc_trap_handler at 0xff2e1148
0xff2e1148: __rtc_trap_handler+0x0058: ld [%l5], %l0
dbx: warning: undefined type number (0,158) at /export/home/husam/release/lib/libstorage_s.so.1:backend.c stab #207 sqlca:(0,158),
assuming type `int {assumed}'
dbx: warning: undefined type number (0,211) at /export/home/husam/release/lib/libstorage_s.so.1:backend.c stab #530 host:(0,211),
assuming type `int {assumed}'
dbx: warning: undefined type number (0,212) at /export/home/husam/release/lib/libstorage_s.so.1:backend.c stab #531 pwd:(0,212),
assuming type `int {assumed}'
dbx: warning: undefined type number (0,213) at /export/home/husam/release/lib/libstorage_s.so.1:backend.c stab #532 usrid:(0,213),
assuming type `int {assumed}'
dbx: warning: undefined type number (0,214) at /export/home/husam/release/lib/libstorage_s.so.1:backend.c stab #533 address:(0,214),
assuming type `int {assumed}'
dbx: warning: undefined type number (0,228) at /export/home/husam/release/lib/libstorage_s.so.1:backend.c stab #577 module:(0,228),
assuming type `int {assumed}'
dbx: warning: undefined type number (0,237) at /export/home/husam/release/lib/libstorage_s.so.1:backend.c stab #638 data:(0,237),
assuming type `int {assumed}'
dbx: warning: undefined type number (0,238) at /export/home/husam/release/lib/libstorage_s.so.1:backend.c stab #639 dest:(0,238),
assuming type `int {assumed}'
dbx: warning: undefined type number (0,846) at /export/home/husam/release/lib/libstorage_s.so.1:backend.c stab #1136 username:G(0,846),
assuming type `int {assumed}'
Current function is queue_message
751 EXEC SQL CALL p_message.queue(:seq,:dest, :data, :notempty, :ret);
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
current thread: t@10
[1] sqlscht(0x48708, 0x47914, 0xa, 0x1, 0x3, 0xa), at 0xfe8cd0f8
[2] sqldbid(0x48708, 0xfacf8aa8, 0x4dbf8, 0xff0d180c, 0x4, 0x390), at 0xfe8b0fec
[3] sqlexp(0x48708, 0x1, 0x7a, 0x7a, 0xfacf8aa8, 0xfedecb18), at 0xfe8b4208
[4] sqlcmex(0x0, 0x4dbf8, 0xfacf8aa8, 0xff0d18a6, 0xfedecafc, 0xfee1689c), at 0xfe8ab770
[5] sqlcxt(0xfacf9cac, 0xff0e3d84, 0xfacf8aa8, 0xff0d18a6, 0xfacf9d48, 0xa), at 0xfe8abdbc
Segmentation Fault (core dumped)
Some iformation you might need:
Compiler : code compiled with cc version 6.2
Debugger : 6.2 patch 111683-03
OS : Solaris 8 patch 108528-12
Machine : E250
Thanks

/export/home/husam/release/lib/libstorage_s.so.1:backend.c stab #530 host:(0,211),The key to your problem is probably the stabs reading error.
How was backend.c compiled?
Normally dbx will load stabs information on demand as needed.
You can start dbx and use the "module" command to load
the stabs information right away without running the program or using RTC.
Try this:
(dbx) module backend.o
Does that cause the stabs warnings?
If you can "repair" or "normalize" the stabs information in that module,
the crash will probably go away.

Runtime checks, multithreaded, C++ 5, dbx

I am trying to use the runtime checking in dbx 5.0
It is a multi threaded application.
When I turn on access checking I get...
Enabling Error Checking... dbx: warning: The loadobject `libjava.so' is stripped, RTC may not catch all the errors
signal SEGV (no mapping at the fault address) in timutex_unlock at 0xf051be8c
0xf051be8c: timutex_unlock+0x001c: ldstub [%g7 + 0x30], %g0
dbx: Stopped within call to '__rtc_reserve_heap_region'. Starting new command interpreter
Any ideas

Thanks but I have it fully patched, and I have searched the release notes, web sites etc. and found nothing. I realise that 5.0 is quite old but that is what the app was compiled with, and it's that app that the customer is having problems with.
So I resorted to this forum, hoping that someone may have concrete information. I know that there was a recognised problem (if not by Sun, then certainly by users) with the RTC in 5.0 for multi-threaded applications, but I was unable to find any reference to it anywhere on the sun/forte web sites. Maybe it got lost in the change to Forte?
Anyway, I believe I have found (and fixed) the problem.
Sorry for the rant, but why do people insist on answering questions that they don't know the answer to.

Persuading dbx to use recompiled object files

When loading a core file, I get:
dbx: warning: Object file is not the same one that was linked into executable.
Skipping stabs. (see `help finding-files')
because I recompiled the object files as the originally compiled object files are no longer available. How can I force dbx to use the newly compiled object files -- they should be identical to the original as I have used the exact same source C++ code?
The core files are hard to replicate, so I can't just recompile and rerun the program.
Thanks

Classic, I worked it out, but for the record, the module command can be used to reload the symbols:
(dbx) module -f myfile.o

DBX error in Sun Studio 9 on Sun 5.10

Hello this topic is the "following" of this one : http://forums.sun.com/thread.jspa?threadID=5333342&tstart=0
Indeed I thought the problem was solved but it wasn't.
I will try to find new elements to provide you with.

Ok for the pstack I will run it on the next try
regarding the patch, I alrerady tried but the patch refused to be installed because no patch was installed before !?
more over when I tried to installed previous patch, it was refused too because they are obsolete ! :/
by the way, yesterday I found a log with this inside
dbx: can't stat /opt/HCLT/presenter/4.2/ee21/c/libdbg/libndcorex.so -- No such file or directory
Reading libndcorex.so
dbx: warning: Couldn't open file: /opt/HCLT/presenter/4.2/ee21/c/libdbg/libndcorex.so (No such file or directory)
dbx: internal error: Can't read /opt/HCLT/presenter/4.2/ee21/c/libdbg/libndcorex.so
Reading libXext.so.0
dbx: warning: The corefile has a different ELF checksum for /usr/lib/libXext.so.0
checksums are: file: 0x43e6 core: 0xf768
See `help core mismatch' for more details.
dbx: can't stat /opt/HCLT/presenter/4.2/ee21/c/libdbg/libndsec.so -- No such file or directory
Reading libndsec.so
dbx: warning: Couldn't open file: /opt/HCLT/presenter/4.2/ee21/c/libdbg/libndsec.so (No such file or directory)
dbx: internal error: Can't read /opt/HCLT/presenter/4.2/ee21/c/libdbg/libndsec.so
dbx: can't stat /opt/HCLT/presenter/4.2/ee21/c/libdbg/libndoaba.so -- No such file or directory
Reading libndoaba.so
dbx: warning: Couldn't open file: /opt/HCLT/presenter/4.2/ee21/c/libdbg/libndoaba.so (No such file or directory)
dbx: internal error: Can't read /opt/HCLT/presenter/4.2/ee21/c/libdbg/libndoaba.so
Reading libdga.so.1
dbx: warning: The corefile has a different ELF checksum for /usr/openwin/lib/libdga.so.1
checksums are: file: 0xd9a9 core: 0xb265
See `help core mismatch' for more details.
Reading libc_psr.so.1
dbx: warning: The corefile has a different ELF checksum for /usr/lib/libthread.so.1
checksums are: file: 0x909e core: 0xe33b
See `help core mismatch' for more details.
dbx: core file read error: address 0xfe6dd698 not in data space
dbx: warning: could not initialize libthread_db.so -- generic libthread_db.so error
dbx: warning: thread related commands will not be available
dbx: warning: see `help lwp', `help lwps' and `help where'
(l@1) terminated by signal ABRT (Abort)The strange point is that presenter 4.2 has never been installed on this machine, we're running Presenter 5.3 !?

Dbx not working in Linux

I am using RedHat 6.5 Linux
Linux version 2.6.32-431.el6.x86_64
I am using Oracle SolarisStudio12.3 to build my application and run in Linux machine.
Binaries are built as 32 bit which are deployed in 64 bit Linux OS.
I am getting the following error while using dbx on my binary:
[dncs@dncs dncs]$ /opt/oracle/solarisstudio12.3/bin/dbx -xexec32 bin/myapp
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc
Reading myapp
Reading ld-linux.so.2
dbx: fetch at 0xef40 failed -- Input/output error
dbx: warning: could not put in breakpoint
dbx: warning: internal handler (-80) made defunct -- could not enable event BPT
dbx: warning: internal handler (-86) made defunct -- could not enable event BPT
Let me know if you need more information on this issue.

The symptom looks like CR 19345519 (dbx does not handle AT_BASE properly on some variants of Linux systems). The problem has been fixed in Oracle Solaris Studio 12.4.

Dbx: warning

Similar Messages

Maybe you are looking for