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

[Kevin Walls]

It looks good Poonam! 8-)

On 10/02/12 05:00, 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/>

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