[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-mdb-discuss
Subject:    Re: [mdb-discuss] How to analyzing core which are generated on
From:       Vishal Thakur <Vishal_Thakur () symantec ! com>
Date:       2010-12-11 14:16:27
Message-ID: 4C00E3275F205744A3440D635BB9D0F04F75C2D31B () APJ1XCHEVSPIN30 ! SYMC ! SYMANTEC ! COM
[Download RAW message or body]

Thanks James and Dmitry for clarifying this.

I raised this query 'coz sometimes the pstack of the core taken from customer system \
does not match with the stack shown by the same core on our local setup.

So, if I understood your point correctly then:
1. Mdb will load the default modules from /usr/platform/%p/lib/mdb/proc or \
/usr/lib/mdb/proc, if not overridden with -L option, else it will load the modules \
from the location specified by -L option. 2. The modules for e.g. libc.so.1, will \
contain dcmds or walkers to display the information of libc.so.1 library. In addition \
to this it may also have declaration for structure/union used in libc.so.1 library. \
Same is true for other modules. 3. If I have some custom shared library and I wanted \
to display information related with that shared library in managed way, then for sure \
I have to create an module corresponding to that shared library. Which I can load \
using ::load command.

Please let me know if this is OK so far.

Next query:
Consider that core.file is generated by xyz process and consider that "ldd xyz" show \
following dependency (/usr/lib/libCstd.so.1, /lib/libc.so.1, \
/usr/lib/customlib.so.1).

I took output of the command "mdb core.file". From this output, I figured out that \
mdb tries to open all the dependent libraries of the xyz process from my local \
system. ================================
open("/usr/lib/customlib.so.2", O_RDONLY)      = 8
open("/usr/lib/libCstd.so.1", O_RDONLY)         = 9
open("/lib/libc.so.1", O_RDONLY)                = 4
================================
It is quite possible that the version of these libraries are different on both the \
system (system on which application dumped core vs system on which I am debugging the \
core). So, 1. Can this lead to an wrong analysis? And what we can do to reduce this \
risk? 2. If cores file contain all the information then why mdb is loading these \
libraries. 3. If I create an chrooted environment then will that solve all the \
problems? and apart from "ldd xyz" what all libraries, I need to copy from customer \
setup? I guess, I have to copy libraries from /usr/lib/mdb/proc location, as these \
modules can also differ based on the OS releases.

Thanks & Regards,
Vishal Thakur


-----Original Message-----
From: Dmitry Samersoff [mailto:Dmitry.Samersoff@oracle.com] 
Sent: Thursday, December 09, 2010 6:55 PM
To: James Carlson
Cc: vishal thakur; mdb-discuss@opensolaris.org
Subject: Re: [mdb-discuss] How to analyzing core which are generated on different \
machine

James,

On 2010-12-09 16:02, James Carlson wrote:
> In general, the information you need about the libraries that were in
> the process's address space comes from the core file itself.  Unlike
> some other debuggers, you shouldn't need copies of the original binaries.

It's work for Solaris 10 only and only if admin doesn't disable it,
in all other case you need a copy of original shared objects.



-- 
Dmitry Samersoff
J2SE Sustaining team, SPB04
* Give Rabbit time and he'll always get the answer ...

_______________________________________________
mdb-discuss mailing list
mdb-discuss@opensolaris.org


[prev in list] [next in list] [prev in thread] [next in thread]