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

[yumin.qi at oracle.com]

  Send on open alias.

On 2/9/2012 9:45 PM, Yumin Qi wrote:
> looks good.
>
> Thanks
> Yumin
>
> On 2012/2/9 21:05, Poonam Bajaj wrote:
>> Not sure if everyone is subscribed to 
>> serviceability-dev at openjdk.java.net..so forwarding it. ]
>>
>> I got one review from David Holmes and need one more review to push 
>> this change to hsx/hotspot-rt. Could someone please review this change.
>>
>> Thanks,
>> Poonam
>>
>> -------- Original Message --------
>> Subject: 	Re: Review Request: 7009098: SA cannot open core files 
>> larger than 2GB on Linux 32-bit
>> Date: 	Fri, 10 Feb 2012 10:30:52 +0530
>> From: 	Poonam Bajaj <poonam.bajaj at oracle.com>
>> Organization: 	Oracle Corporation
>> To: 	serviceability-dev at openjdk.java.net
>>
>>
>>
>> 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/f95b65cf/attachment.html