James McPherson wrote On 03/11/06 12:18 PM,:
On 11/3/06, Hema Huchegowda <[EMAIL PROTECTED]> wrote:
Is there a way in mdb to specify the library path (similar to
pathmap in dbx) so I can open the application core on target
systems that doesn't have to be running at the same patch
level as the system where the application core dumped..
Hi Hema,
There are two parts to this - firstly there is the dmod path, for which
you use "::set -L". I did this quite a lot when testing new dmods for
leadvile:
:: set -L /path/to/new/dmod:%o
which specifies the dmod library path.
For mappings, you need to have a look at
http://docs.sun.com/app/docs/doc/816-5041/6mb7ae3ll?q=library+path&a=view
and check the section on "-o option" particularly for the showlmid
option. Once
you've done that, have a look into the private mappings available with
::nm -P.
Hi James,
Thanks for responding:
I tried what you suggested and that didn't seem to help me.
The core is from a solaris 9 box and I'm trying to read it from a
solaris 10 system:
I've brought in all the libraries this application dependents (as seen
in pldd output) on to the target system and placed them under: /test/libs
Here is what I tried:
# mdb -o showlmid java core.1161951717
mdb: warning: core file is from SunOS 5.9 Generic_118558-27; shared text
mappings may not match installed libraries
mdb: failed to initialize /usr/lib/libthread_db.so.1: libthread_db call
failed unexpectedly
mdb: warning: debugger will only be able to examine raw LWPs
mdb: couldn't read cache at 0: no mapping for address
Loading modules: [ libumem.so.1 libc.so.1 ]
> ::set -L /test/libs:%o
> ::objects
BASE LIMIT SIZE NAME
10000 20000 10000 LM0`java
ff370000 ff38a000 1a000 LM0`/usr/lib/libumem.so.1
ff340000 ff358000 18000 LM0`/usr/lib/libthread.so.1
ff3f2000 ff3f4000 2000 LM0`/usr/lib/libdl.so.1
ff200000 ff2ac000 ac000 LM0`/usr/lib/libc.so.1
ff3b8000 ff3bc000 4000 LM0`/usr/platform/sun4u/lib/libc_psr.so.1
fec00000 ff14a000 54a000
LM0`/usr/jdk1.5.0_07/jre/lib/sparc/client/libjvm.so
ff2e0000 ff2ea000 a000 LM0`/usr/lib/libsocket.so.1
ff1e0000 ff1e2000 2000 LM0`/usr/lib/libsched.so.1
ff1b0000 ff1bc000 c000 LM0`/usr/lib/libCrun.so.1
febb0000 febe8000 38000 LM0`/usr/lib/libm.so.1
fea80000 feb0e000 8e000 LM0`/usr/lib/libnsl.so.1
feb90000 feb94000 4000 LM0`/usr/lib/libmp.so.2
feb40000 feb48000 8000
LM0`/usr/jdk1.5.0_07/jre/lib/sparc/native_threads/libhpi.so
fea30000 fea3e000 e000 LM0`/usr/jdk1.5.0_07/jre/lib/sparc/libverify.so
fe9f0000 fea14000 24000 LM0`/usr/jdk1.5.0_07/jre/lib/sparc/libjava.so
fe9c0000 fe9d0000 10000 LM0`/usr/jdk1.5.0_07/jre/lib/sparc/libzip.so
fe7c0000 fe7c4000 4000
LM0`/usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
c2550000 c2562000 12000 LM0`/usr/jdk1.5.0_07/jre/lib/sparc/libnet.so
c23e0000 c23e6000 6000 LM0`/usr/jdk1.5.0_07/jre/lib/sparc/libnio.so
c23c0000 c23c6000 6000 LM0`/usr/lib/librt.so.1
Just for comparison, I've included the proc -map output from dbx as well.
As you can see, in dbx, all the libs are mapped neatly but I can't get
this working in mdb.
I tried set -L as below and that didn't help either:
::set -L /test/libs/lib/libthread_db.so.1/%o
::set -L /test/libs/lib:%o
(dbx) proc -map
Loadobject mappings for current core file:
0x00010000 /usr/jdk1.5.0_07/bin/java
0xff370000 /usr/lib/libumem.so.1
0xff340000 /usr/lib/libthread.so.1
0xff3f2000 /usr/lib/libdl.so.1
is being filtered by: /usr/lib/ld.so.1
0xff200000 /usr/lib/libc.so.1
is being filtered by:
/usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
0xff3b8000 /usr/platform/sun4u/lib/libc_psr.so.1
0xfec00000 /usr/jdk1.5.0_07/jre/lib/sparc/client/libjvm.so
0xff2e0000 /usr/lib/libsocket.so.1
0xff1e0000 /usr/lib/libsched.so.1
0xff1b0000 /usr/lib/libCrun.so.1
0xfebb0000 /usr/lib/libm.so.1
0xfea80000 /usr/lib/libnsl.so.1
0xfeb90000 /usr/lib/libmp.so.2
0xfeb40000 /usr/jdk1.5.0_07/jre/lib/sparc/native_threads/libhpi.so
0xfea30000 /usr/jdk1.5.0_07/jre/lib/sparc/libverify.so
0xfe9f0000 /usr/jdk1.5.0_07/jre/lib/sparc/libjava.so
0xfe9c0000 /usr/jdk1.5.0_07/jre/lib/sparc/libzip.so
0xfe7c0000 /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
0xc2550000 /usr/jdk1.5.0_07/jre/lib/sparc/libnet.so
0xc23e0000 /usr/jdk1.5.0_07/jre/lib/sparc/libnio.so
0xc23c0000 /usr/lib/librt.so.1
0xc23a0000 /usr/lib/libaio.so.1
0xc38e0000 /usr/lib/libmd5.so.1
is being filtered by:
/usr/platform/SUNW,Sun-Blade-1000/lib/libmd5_psr.so.1
0xc3590000 /usr/jdk1.5.0_07/jre/lib/sparc/libmanagement.so
0xc0fa0000 /usr/lib/libsendfile.so.1
0xbcc80000 /prod/ondemand/www/libarswwwsl.so
0xbcb00000 /prod/ondemand/lib/libicuuc30.so
0xc0ea0000 /prod/ondemand/lib/libicudata30.so
0xc0de0000 /usr/lib/libpthread.so.1
is being filtered by: libthread.so.1
0xbc980000 /prod/ondemand/lib/libicui18n30.so
0xc0ce0000 /usr/lib/nss_files.so.1
0xff3c0000 /usr/lib/ld.so.1 [LM_ID_LDSO]
--Hema
cheers,
James C. McPherson
--
Solaris kernel software engineer, system admin and troubleshooter
http://www.jmcp.homeunix.com/blog
Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson
--
Hema Huchegowda, Java Support Engineer
TSC Software - Java
Sun Microsystems, Australia Pty Ltd.
x57060/+61 2 98445060/+61 410-441-225
[EMAIL PROTECTED]
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
