I am encountering an issue trying to debug programs compiled with SS 12.3 in a Linux environment.
The target environment is a customized Wind River Linux distribution that we deploy. I understand that Oracle only officially supports RHEL and OEL - I was just hoping someone who is an expert could possibly chime in with some clues to help us make this work.
Some relevant background info:
Linux msclab66 2.6.27-pne #1 SMP Wed May 9 17:49:29 CDT 2012 x86_64 x86_64 x86_64 GNU/Linux
Note - we don't deploy any 64-bit libraries in our environment. These are all 32-bit libraries and programs.
dbx is unable to initalize the 'thread debugging library'.
Yes, there are some issues with name demangling, but I'm not as concerened about that right now. I'm not as worried about debugging libstdc++ code as I am having the ability to debug multithreaded programs properly. As it stands, dbx is pretty much useless for us because it can't do anything thread-related.
Another note - We have a RHEL 5.7 system that is fully capable of debugging this the same program /w threading support working correctly.
Any bit of advice here are greately appreciated.
msclab66# /opt/oracle/solarisstudio12.3/bin/dbx -xexec32 /opt/SANTone/msc/10.01.00.00/bin/CsFm
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc
dbx: internal warning: cannot demangle '__14COdbcSQLTables'
dbx: internal warning: cannot demangle '__14__si_type_infoPCcRC16__user_type_info'
dbx: internal warning: cannot demangle '__13bad_exception'
<snipped the rest of the libstdc++ warnings for brevity>
Reading libgcc_s.so.1 dbx: warning: could not initialize thread debugging library -- program is not linked with libthread dbx: warning: thread related commands will not be available dbx: warning: see `help lwp', `help lwps' and `help where'
Here is the output of ldd on the CsFm executable. It's linked with libpthread.so.
Dbx relies on a system-supplied library, libthread_db.so with an interface specified in /usr/include/thread_db.h.
The error message: "program is not linked with libthread" corresponds to the TD_NOLIBTHREAD returned by
the call to td_init().
libthread_db.so provides a stable API for debuggers to access libpthread data structures.
Both are supplied by the system.
It's hard to tell why this might be happening. One common case is as follows:
libthread_db.so and libpthread.so have to be "in sync". We've seen, even on Solaris systems, cases
where for example a patch updates libpthread but libthread_db.so gets neglected.
We may be able to tell more if we get some logging information from dbx as follows:
Create a file called "C.dbx" in the directory where you run dbx with content as follows:
options -file L.dbx
LogTDB # call tdb_log(1) fo (thread_db)
LogDB # echo calls from ps_plog
LogPO # proc_service
Reproduce the problem and post the resulting L.dbx.