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

Fri, 10 Feb 2012 08:33:43 -0800 

 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 [email protected] 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 <[email protected]>
Organization:   Oracle Corporation
To:     [email protected]



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

Reply via email to