Hello all,
Do you think that the explanation is reasonable ?
Do you think that just a re-compile can fix it ?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Response from Vendor:
We were able to determine that the reason the core files occur when using
libumem is that the utility is misinterpreting a pointer to a shared memory
structure. The structure is allocated as a 1 element array with additional
space dynamically allocated after it. So when the reference to the additional
structures after the original one is made in the get_next_condition() routine,
it cores thinking that the memory boundary has been past, when in fact, it is
not the case at all.
get_next_condition+0x30()
delete_all_conditions+0xa9()
+++++++++++++++++++++++++++++++++++++++++++++++++++++
Problem:
Core for pm process when LIBUMEM is active.
******************************************************************************
Application core Dump Analysis Output MDeBug Rev 1.0
Mon Jun 16 16:30:53 EDT 2008 Files:
/export/home/omni/bin/pm /unisphere/srx3000/
srx/40/core/core.pm.8388
******************************************************************************
** Core file status **
------------------------
debugging core file of pm (64-bit) from srx114
file: /export/home/omni/bin/pm
initial argv: /export/home/omni/bin/pm -nocheck -restart
threading model: multi-threaded
status: process terminated by SIGSEGV (Segmentation Fault)
** Thread stack($c) **
----------------------
get_next_condition+0x30()
delete_all_conditions+0xa9()
handlePmRealignResponse+0x18c()
main+0x13db()
_start+0x6c()
** Shared objects **
----------------------
BASE LIMIT SIZE NAME
fffffd7fff3b5000 fffffd7fff3ea000 35000 /lib/amd64/ld.so.1
400000 465000 65000 /export/home/omni/bin/pm
fffffd7fff370000 fffffd7fff37d000 d000
/lib/secure/amd64/libgcc_s.so.1
fffffd7fff340000 fffffd7fff341000 1000 /lib/secure/amd64/libilib.so
fffffd7fff2f0000 fffffd7fff30f000 1f000 /lib/amd64/libumem.so.1
fffffd7fff2c0000 fffffd7fff2c5000 5000
/export/home/omni/library/libdgms.so
fffffd7fff250000 fffffd7fff267000 17000
/export/home/omni/library/libapi.so
fffffd7fff230000 fffffd7fff231000 1000
/export/home/omni/library/liblog.so
fffffd7fff200000 fffffd7fff20a000 a000
/export/home/omni/library/libulcmtoolsc.so
fffffd7fff1b0000 fffffd7fff1ba000 a000
/export/home/omni/library/libdf.so
fffffd7fff150000 fffffd7fff176000 26000
/export/home/omni/library/libFt.so
fffffd7fff120000 fffffd7fff12f000 f000 /lib/amd64/libsocket.so.1
fffffd7fff040000 fffffd7fff0e5000 a5000 /lib/amd64/libnsl.so.1
fffffd7fff020000 fffffd7fff022000 2000 /usr/lib/amd64/libl.so.1
fffffd7ffeff0000 fffffd7ffeff7000 7000 /lib/amd64/libgen.so.1
fffffd7fff390000 fffffd7fff394000 4000 /lib/amd64/libpthread.so.1
fffffd7ffefb0000 fffffd7ffefb8000 8000 /lib/amd64/librt.so.1
fffffd7ffeea0000 fffffd7ffef86000 e6000 /lib/amd64/libc.so.1
fffffd7ffee70000 fffffd7ffee7d000 d000
/usr/local/lib/amd64/libgcc_s.so.1
fffffd7ffee40000 fffffd7ffee48000 8000 /lib/amd64/libaio.so.1
fffffd7ffee20000 fffffd7ffee2c000 c000 /lib/amd64/libmd.so.1
fffffd7ffedd0000 fffffd7ffede9000 19000 /lib/amd64/libscf.so.1
fffffd7ffedb0000 fffffd7ffedb2000 2000 /lib/amd64/libdoor.so.1
fffffd7ffed80000 fffffd7ffed89000 9000 /lib/amd64/libuutil.so.1
fffffd7ffed60000 fffffd7ffed64000 4000 /lib/amd64/libmp.so.2
Thread stack for MT app
------------------------
stack pointer for thread 1: fffffd7fffdfa390
[ fffffd7fffdfa390 get_next_condition+0x30() ]
fffffd7fffdfa3d0 delete_all_conditions+0xa9()
fffffd7fffdfa6c0 handlePmRealignResponse+0x18c()
fffffd7fffdfde50 main+0x13db()
fffffd7fffdfde60 _start+0x6c()
#
This message posted from opensolaris.org
