Things to Remember

Keep the following things in mind when debugging a mismatched core file:

• The pathmap command does not recognize a pathmap for ’/’ so you cannot use the following command:

  pathmap / /net/core-host

• The single-argument mode for the pathmap command does not work with loadobject pathnames, so use the two argument from-path to-path mode.

• Debugging the core file is likely to work better if the dbx-host has either the same or a more recent version of the Solaris operating environment than the core-host, though this is not always necessary.

• The system libraries that you might need are:

  • For the runtime linker:

    /usr/lib/ld.so.1

    /usr/lib/librtld_db.so.1

    /usr/lib/64/ld.so.1

    /usr/lib/64/librtld_db.so.1

  • For the threads library, depending on which implementation of libthread you are using:

    /usr/lib/libthread_db.so.1

    /usr/lib/64/libthread_db.so.1

    /usr/lib/lwp/libthread_db.so.1

    /usr/lib/lwp/64/libthread_db.so.1

    The /usr/lib/lwp files apply only if you are running dbx in the Solaris 8 operating environment and only if you are using the alternate libthread library.

    You will need the 64-bit versions of the xxx_db.so libraries if dbx is running on a 64-bit capable version of the Solaris OS since these system libraries are loaded and used as part of dbx, not as part of the target program.

    The ld.so.1 libraries are part of the core file image like libc.so or any other library, so you need the 32-bit ld.so.1 library or 64-bit ld.so.1 library that matches the program that created the core file.

• If you are looking at a core file from a threaded program, and the where command does not display a stack, try using lwp commands. For example:.

  (dbx) where current thread: t@0 [1] 0x0(), at 0xffffffff (dbx) lwps o>l@1 signal SIGSEGV in _sigfillset() (dbx) lwp l@1 (dbx) where =>[1] _sigfillset(), line 2 in "lo.c" [2] _liblwp_init(0xff36291c, 0xff2f9740, ... [3] _init(0x0, 0xff3e2658, 0x1, ... ...

  The -setfp and -resetfp options of the lwp command are useful when the frame pointer (fp) of the LWP is corrupted. These options work when debugging a core file, where assign $fp=... is unavailable.

  The lack of a thread stack can indicate a problem with thread_db.so.1 Therefore, you might also want to try copying the proper libthread_db.so.1 library from the core-host.