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

[Daniel D. Daugherty]

On 2/9/12 10:00 PM, Poonam Bajaj wrote:
> 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/>

Thumbs up.

agent/src/os/linux/Makefile
     No comments.

agent/src/os/linux/libproc_impl.c
     No comments.

make/linux/makefiles/saproc.make
     No comments.

Dan


>
>
> 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/2bb12c72/attachment-0001.html