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

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.. :)

2012-04-03 22:53
by tfinniga

What if you step by machine instruction through the destructor call? What library do you end up inside - Zan Lynx 2012-04-03 23:41

@ZanLynx thanks, I ended up stepping into the operator new in a small project that linked against different libraries, and finally narrowed it down to the one that was returning a different value from the constructor - tfinniga 2012-04-04 16:15

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.

2012-04-04 04:43
by leedm777