Review Request: 7009098: SA cannot open core files larger than 2GB on Linux 32-bit
poonam.bajaj at oracle.com
Thu Feb 9 21:00:52 PST 2012
Could I have one more review for this change, please.
7009098: SA cannot open core files larger than 2GB on Linux 32-bit
On 2/9/2012 12:29 PM, Poonam Bajaj wrote:
> On 2/9/2012 12:21 PM, David Holmes wrote:
>> Hi Poonam,
>> On 9/02/2012 4:42 PM, Poonam Bajaj wrote:
>>>>> There is one more change with which SA should first load libraries
>>>>> from the path specified with SA_ALTROOT rather than loading from
>>>>> the host system.
>>>> Where does this come from? It is not related to this CR. Is there
>>>> another CR indicating the current behaviour is incorrect? Or a spec
>>>> for it that indicates it is incorrect?
>>> This change became necessary to open the same customer provided core
>>> which required the first change. There is no separate bug filed for
>> Actually there is: 7009089
> Thanks for finding this bug number. I will link both the bugs.
>> Thanks for all the info. Your change agrees with the proposed fix in
>> 7009089, and it seems consist with how Solaris checks the alt-root
>> path first.
>> So this looks good to me.
>>> There is a document in the hotspot repository
>>> hotspot/agent/doc/transported_core.html which talks about the
>>> transported cores and the use of SA_ALTROOT.
>>> " The best possible way to debug a transported core dump is to match
>>> debugger machine to that of core dump machine. i.e., have same Kernel
>>> and libthread patch level between the machines. mdb (Solaris modular
>>> debugger) may be used to find the Kernel patch level of core dump
>>> machine and debugger machine may be brought to the same level.
>>> If the matching machine is "far off" in your network, then
>>> * consider using rlogin and CLHSDB - SA command line HSDB interface
>>> * use SA remote debugging and debug the core from core machine
>>> But, it may not be feasible to find matching machine to debug. If so,
>>> you can copy all application shared objects (and libthread_db.so, if
>>> needed) from the core dump machine into your debugger machine's
>>> directory, say, /export/applibs. Now, set *SA_ALTROOT* environment
>>> variable to point to /export/applibs directory. Note that
>>> /export/applibs should either contain matching 'full path' of
>>> i.e., /usr/lib/libthread_db.so from core machine should be under
>>> /export/applibs/use/lib directory and
>>> /use/java/jre/lib/sparc/client/libjvm.so from core machine should be
>>> under /export/applibs/use/java/jre/lib/sparc/client so on or
>>> /export/applibs should just contain libthread_db.so, libjvm.so etc.
>>> directly. "
>>> " On Linux, SA parses core and shared library ELF files. SA *does not*
>>> use libthread_db.so or rtld_db.so for core dump debugging (although
>>> libthread_db.so is used for live process debugging). But, you may still
>>> face problems with transported core dumps, because matching shared
>>> objects may not be in the path(s) specified in core dump file. To
>>> workaround this, you can define environment variable *SA_ALTROOT* to be
>>> the directory where shared libraries are kept. The semantics of this
>>> env. variable is same as that for Solaris (please refer above)."
>>> So, if SA_ALTROOT is specified, libraries from this path should get
>>> loaded and not from the path embedded in the core file.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the serviceability-dev