segfaults during cleanup

i’ve got an application build with boost-1.37 (among other libraries). it appears to run, but dies when the dtors are called.

Is there a problem with the order of the shared libraries? i see some libc and libpgc which could conflict?

host > app
app runs nicely and gives results equivalent to intel and g++
then…
============= TEST COMPLETE ===========

C++ runtime abort: terminate() called by the exception handling mechanism
Abort
host> ldd /local/mcatk/users/sdnolen/workspace/obj/pgi-opt/src/Interface/fi_test/Interface_fi_tester_run
libboost_filesystem-mt-1_37-pgi10.so => /local/mcatk/packages/lib/libboost_filesystem-mt-1_37-pgi10.so (0x0000002a95557000)
libboost_signals-mt-1_37-pgi10.so => /local/mcatk/packages/lib/libboost_signals-mt-1_37-pgi10.so (0x0000002a956c7000)
libboost_mpi-mt-1_37-pgi10.so => /local/mcatk/packages/lib/libboost_mpi-mt-1_37-pgi10.so (0x0000002a9583e000)
libboost_program_options-mt-1_37-pgi10.so => /local/mcatk/packages/lib/libboost_program_options-mt-1_37-pgi10.so (0x0000002a95aaf000)
libboost_system-mt-1_37-pgi10.so => /local/mcatk/packages/lib/libboost_system-mt-1_37-pgi10.so (0x0000002a95d94000)
libboost_serialization-mt-1_37-pgi10.so => /local/mcatk/packages/lib/libboost_serialization-mt-1_37-pgi10.so (0x0000002a95ea0000)
libloki-pgi.so.0.1.7 => /local/mcatk/packages/lib/libloki-pgi.so.0.1.7 (0x0000002a96374000)
libtbb.so.2 => /local/mcatk/packages/src/tbb-2.0.17/build/linux_em64t_pgi_cc4.3.3_libc2.3.4_kernel2.6.9_release/libtbb.so.2 (0x0000002a9649a000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000003f9d100000)
libmpi_cxx.so.0 => /local/mcatk/packages/lib/libmpi_cxx.so.0 (0x0000002a965ec000)
libmpi.so.0 => /local/mcatk/packages/lib/libmpi.so.0 (0x0000002a96707000)
libopen-rte.so.0 => /local/mcatk/packages/lib/libopen-rte.so.0 (0x0000002a968b0000)
libopen-pal.so.0 => /local/mcatk/packages/lib/libopen-pal.so.0 (0x0000002a969f8000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003f9cb00000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003fa4800000)
libutil.so.1 => /lib64/libutil.so.1 (0x0000003f9ef00000)
libm.so.6 => /lib64/tls/libm.so.6 (0x0000003f9c900000)
libnuma.so => /usr/lib64/libnuma.so (0x0000003f9c400000)
libpgbind.so => /opt/local/vendor/pgi-10.1/10.1/share_objects/lib64/libpgbind.so (0x0000002a96b6f000)
libstd.so => /opt/local/vendor/pgi-10.1/linux86-64/10.1/libso/libstd.so (0x0000002a96c71000)
libC.so => /opt/local/vendor/pgi-10.1/linux86-64/10.1/libso/libC.so (0x0000002a96edb000)
libpgc.so => /opt/local/vendor/pgi-10.1/linux86-64/10.1/libso/libpgc.so (0x0000002a96ff3000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000003f9c600000)
librt.so.1 => /lib64/tls/librt.so.1 (0x0000003fa1000000)
/lib64/ld-linux-x86-64.so.2 (0x0000003f9c200000)
libstdc++.so.6 => /local/mcatk/packages/lib/…/lib64/libstdc++.so.6 (0x0000002a97149000)
libgcc_s.so.1 => /local/mcatk/packages/lib/…/lib64/libgcc_s.so.1 (0x0000002a97354000)

the only library not build specifically with PGI was the openmpi one, but we are only using the c-interface from this (or at least boost is)

Hello,

I will try to answer what I can.

We have been getting better at boost, but have not built it all,
and I am not sure what runs.

wrt libc and libpgc, libpgc calls libc routines. We found several years ago
that libc routines would change the number, order, and type of arguments
passed to them from release to release. We created libpgc to have a consistent
interface. For each linux system we installed, a version of libpgc was created
to handle the libc version on that lionux system.

Our runtime libs call routines from the shared libpgc.so, which is
installed to compliment the version of libc.so resident. In theory,
you can compile on machine A with libc.so version A and
run it on machine B with its libc.so version B, as long as you install
libpgc.so that was created for libc.so version B on platform B.

Today, libc.so has a consistent interface across most linux systems, and
so libpgc.so is the same for all targets. Should differences crop up again,
we may need multiple libpgc.so files again.

regards,
dave