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

[David Holmes]

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 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.

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
>>> --
>>>
>>>