Discussion:
Segmentation fault when using libhoard memory allocat and getting core dump
Kishore Kumar Pusukuri
2010-08-10 23:39:59 UTC
Permalink
I am trying to see the impact of different memory allocators on multi-threaded workloads on my AMD machine running OpenSolaris 2009.06. I successfully used libmtmalloc and libumem, however, it is giving core dump (through SEG fault) when I used libhoard_32.so. However, I didn't get any errors when I compiled using libhoard_32.so. Moreover, it is fine when I used number of threads from 1 to 6. It is giving core dump with 7 threads and above,

I compiled a multi-threaded program called "swaptions". I also provided the stack trace of the core dump. Could you please tell me the problem? Any directions to find the actual problem please.

$ file /usr/lib/libhoard_32.so
/usr/lib/libhoard_32.so: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE2 SSE AMD_3DNow CMOV], dynamically linked, not stripped

$ ldd swaptions
libpthread.so.1 => /lib/libpthread.so.1
/usr/lib/libhoard_32.so
libCrun.so.1 => /usr/lib/libCrun.so.1
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1
libthread.so.1 => /usr/lib/lwp/libthread.so.1
libdl.so.1 => /lib/libdl.so.1

$ mdb core
Loading modules: [ ld.so.1 ]
::stack
libhoard_32.so`__1cFHoardMHoardManager4n0AVAlignedSuperblockHeap4nCHLMSpinLock
Type_udsyQ__n0AKGlobalHeap4udsyQiIn0C___n0APHoardSuperblock4n0C_idsyQn0AJSmall
Heap___iIn0C_n0AbBhoardThresholdFunctionClass_n0F__Gmalloc6MI_pv_+0x12d(
fef155b4, 1088, febdfee4, feefad51)
libhoard_32.so`__1cCHLKHybridHeap4ibwjWnFHoardOThreadPoolHeap4ibnKieYn0BSPerTh
readHoardHeap___n0BHBigHeap__Gmalloc6MI_pv_+0x82(fef13850, 1088, fd9c2d48,
feef8364)
libhoard_32.so`malloc+0xe3(1088, fd9c2d78, feefe59d, fef155b4)
_Z7dmatrixllll+0x51(0, 2, 0, af, fef11d50, fd9c2dac)
_Z28HJM_SimPath_Forward_BlockingPPdiidS_S_S0_Pli+0x51(fe4d0224, b, 3, 0,
40160000, fea83ac8)
_Z21HJM_Swaption_BlockingPddddddiidS_PS_llii+0x438(fd9c2fa4, 9999999a,
3fb99999, 0, 0, 0)
_Z6workerPv+0xae(8047c48, fed4f000, fd9c2fec, fecbcd1e)
libc_hwcap2.so.1`_thrp_setup+0x7e(fe937400)
libc_hwcap2.so.1`_lwp_start(fe937400, 0, 0, fecbcd1e, 0, 0)
::status
debugging core file of swaptions (32-bit) from opensolaris
....
...
threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault), addr=C
--
This message posted from opensolaris.org
Darryl Gove
2010-08-11 00:41:10 UTC
Permalink
If you can build with Studio instead you could use the thread analyzer
to track down data races. If not you should look at helgrind, part of
valgrind.

Regards,

Darryl.
Post by Kishore Kumar Pusukuri
I am trying to see the impact of different memory allocators on multi-threaded workloads on my AMD machine running OpenSolaris 2009.06. I successfully used libmtmalloc and libumem, however, it is giving core dump (through SEG fault) when I used libhoard_32.so. However, I didn't get any errors when I compiled using libhoard_32.so. Moreover, it is fine when I used number of threads from 1 to 6. It is giving core dump with 7 threads and above,
I compiled a multi-threaded program called "swaptions". I also provided the stack trace of the core dump. Could you please tell me the problem? Any directions to find the actual problem please.
$ file /usr/lib/libhoard_32.so
/usr/lib/libhoard_32.so: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE2 SSE AMD_3DNow CMOV], dynamically linked, not stripped
$ ldd swaptions
libpthread.so.1 => /lib/libpthread.so.1
/usr/lib/libhoard_32.so
libCrun.so.1 => /usr/lib/libCrun.so.1
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1
libthread.so.1 => /usr/lib/lwp/libthread.so.1
libdl.so.1 => /lib/libdl.so.1
$ mdb core
Loading modules: [ ld.so.1 ]
::stack
libhoard_32.so`__1cFHoardMHoardManager4n0AVAlignedSuperblockHeap4nCHLMSpinLock
Type_udsyQ__n0AKGlobalHeap4udsyQiIn0C___n0APHoardSuperblock4n0C_idsyQn0AJSmall
Heap___iIn0C_n0AbBhoardThresholdFunctionClass_n0F__Gmalloc6MI_pv_+0x12d(
fef155b4, 1088, febdfee4, feefad51)
libhoard_32.so`__1cCHLKHybridHeap4ibwjWnFHoardOThreadPoolHeap4ibnKieYn0BSPerTh
readHoardHeap___n0BHBigHeap__Gmalloc6MI_pv_+0x82(fef13850, 1088, fd9c2d48,
feef8364)
libhoard_32.so`malloc+0xe3(1088, fd9c2d78, feefe59d, fef155b4)
_Z7dmatrixllll+0x51(0, 2, 0, af, fef11d50, fd9c2dac)
_Z28HJM_SimPath_Forward_BlockingPPdiidS_S_S0_Pli+0x51(fe4d0224, b, 3, 0,
40160000, fea83ac8)
_Z21HJM_Swaption_BlockingPddddddiidS_PS_llii+0x438(fd9c2fa4, 9999999a,
3fb99999, 0, 0, 0)
_Z6workerPv+0xae(8047c48, fed4f000, fd9c2fec, fecbcd1e)
libc_hwcap2.so.1`_thrp_setup+0x7e(fe937400)
libc_hwcap2.so.1`_lwp_start(fe937400, 0, 0, fecbcd1e, 0, 0)
::status
debugging core file of swaptions (32-bit) from opensolaris
....
...
threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault), addr=C
--
Darryl Gove
Compiler Performance Engineering
Blog : http://blogs.sun.com/d/
Books: http://my.safaribooksonline.com/9780321711441
http://my.safaribooksonline.com/9780768681390
http://my.safaribooksonline.com/0595352510
Loading...