Segments in core files...

[David Gourley_1]

We had a JVM core dump with a SIGABORT.

In the past, with C processes I've often found that a SIGABORT has been triggered by hitting a kernel limit (I've actually knocked together a noddy program for looking at the size of segments within core files to help identify this).

In our core file we had a very large segment (333 MB) of type CORE_MMF (see /usr/include/sys/core.h for the list). Unfortunately, CORE_MMF doesn't appear to be very well document.

Which address space quadrant does this map into? (If it maps into the data segment it might explain the core dump I'm seeing).

Thanks in advance

Dave

[Steve Steel · Accepted solution]

Hi

These are Memory Mapped Files

See

/usr/share/doc/proc_mgt.txt

grep -i mapped /usr/include/sys/*.h

grep -i mapped /usr/include/sys/*.h

If you have a HP contract ask them to supply kmeminfo for you

Steve Steel

[Jeff Schussele]

HI Dave,

All shared objects & memory mapped objects live in the 3rd quad by default. If EXEC_MAGIC or SHMEM_MAGIC has been linked (or chatr'd) into the executable, it could also be using a protion of the 4th quad as well.

Rgds,
Jeff

[Mike Stroyan]

A CORE_MMF could be a shared memory mapped file or a private mmap region. The mmap system call can map segments as an image of a file or initialized to zeros. They can be shared or private. Given that it is a java process a 333MB CORE_MMF segment is very likely to be the java heap, which is implemented as private mmap segments. The normal process data segment, (which would look like CORE_DATA), is not used for the java heap.

The 32-bit address space layouts can be changed quite a bit by various linker and chatr options. There is a good table of all the options in the Adaptive Address Space white paper at
http://h21007.www2.hp.com/dspp/files/unprotected/Itanium/aas_white_paper.pdf
The default has private objects mapped into quadrant 2 and shared objects mapped into quadrants 3 and 4. The java executables from HP will also have private data in quadrant 1. There are also java_q3p and java_q4p variants in java 1.3 and 1.4 that have third and fourth quadrant private data.

You really should look at the stack backtraces to get an idea where the process died.

[David Gourley_1]

Thanks all for the help. Unfortunately backtrace complains about inability to access memory :-( All I can tell is that the process died with SIGABORT.

I'm assuming that all CORE_MMF segments will count (along with CORE_DATA segments) towards maxdsiz; if this is the case we aren't close to the maxdsiz limit (with C/C++ processes we've seen them die with SIGABORT when they attempt to allocate memory and would exceed maxdsiz).

Looks like we'll have to see if the recurs or is a one-off :-(

[Mike Stroyan]

You might get better results with a newer gdb.
Check http://www.hp.com/go/wdb to see if you have the latest version.

The maxdsiz limit only affects the data segment, (CORE_DATA). The newer shared memory and memory mapped file interfaces are not counted towards the maxdsiz limit.