Review Request: 7009098: SA cannot open core file larger than 2GB

[Poonam Bajaj]

Hi David,

On 2/9/2012 11:36 AM, David Holmes wrote:
> On 9/02/2012 2:41 PM, Poonam Bajaj wrote:
>> Could I have code reviews for the following fix:
>>
>> 7009098: SA cannot open core file larger than 2GB
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009098
>> Webrev: http://cr.openjdk.java.net/~poonam/7009098/webrev.00/
>>
>> Serviceability Agent on Linux is not able to open core files larger
>> than 2GB. The fix is to enable the 'Large File Support' by compiling
>> the libsaproc.so with -D_FILE_OFFSET_BITS=64. This is added to both
>> agent/src/os/linux/Makefile (which builds SA from agent/make/) and
>> make/linux/makefiles/saproc.make (which builds SA with Hotspot build).
>
> This seems ok.
>
>> 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.

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/20120209/73c7dc39/attachment-0001.html