Review Request: 7009098: SA cannot open core file larger than 2GB

[Poonam Bajaj]

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 this
>> change.
>
> 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.
>
Thanks,
Poonam

> David
> -----
>
>
>>
>> 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 the
>> 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
>> <http://cafebabe.uk.oracle.com/lxr/source/hotspot/agent/doc/clhsdb.html>
>>     or
>>   * use SA remote debugging and debug the core from core machine 
>> remotely.
>>
>> 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 libraries.
>> 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.
>>
>>
>> Thanks,
>> Poonam
>>
>>
>>> David
>>> -----
>>>
>>>>
>>>> Thanks,
>>>> Poonam
>>>> -- 
>>>>
>>>>