Review Request: 7009098: SA cannot open core files larger than 2GB on Linux 32-bit

[Poonam Bajaj]

Hi,

Could I have one more review for this change, please.

7009098: SA cannot open core files larger than 2GB on Linux 32-bit
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098 
<http://monaco.sfbay.sun.com/detail.jsf?cr=7009098>
Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/ 
<http://cr.openjdk.java.net/%7Epoonam/7009098/webrev.00/>


Thanks,
Poonam

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 
>>> 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
>>>>> -- 
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120210/5f5358c9/attachment.html