Inspecting c++ libraries for different stl linkage to track down std::vector destructor crash on gcc/osx?

Question

So I recently started working on a large software project that links in several static and dynamic libraries on OSX, using the llvm-gcc compiler.

I'm having serious problems with the stl. Specifically, very simple code will crash. For example, in my main project, the following code will crash:

{
    std::vector< unsigned int > testvec;
    testvec.resize( 1 );
    testvec[0] = 0;
}

It will crash when exiting the scope, inside of the std::vector< unsigned int > destructor, throwing a SIGABRT and saying that the memory being deallocated hasn't been allocated. Specifically:

malloc: *** error for object 0x135e8fc30: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

This only happens in a release build - the debug build works just fine.

My best guess is that one of the external libraries is linked against another version of the STL that uses a different internal memory layout, so it's trying to dealloc the size or something like that.

I've run nm on all of the libraries I'm linking against, and several of them have external stl symbols (specifically, std::vector< unsigned int > destructor is marked with an S in the nm output). But I can't figure out which one is the culprit.

Is there a way to inspect the .a or dylib files to track down which ones are linking against a different version of the STL?

[edit]

This looks like a real-world example of the situation described in Two static libs, two different vector implementations, what would the linker do? It turns out that the linker does horrible, horrible things.. :)

Answer 1

I believe otool -L is what you're looking for. This will list the shared libraries the program uses.

You should also check out your include path. It seems unlikely, but it's possible that #include <vector> is pulling in a non-standard include, whose definition doesn't match what's in the standard library.