gcc, c++: static string member variarible causes heap corruption/segmentation fault

Question

I have a big application that uses the dynamically loaded libraries. At the end of program while terminating it either segfaults or spits a message "glibc detected corrupted double-linked list". Looking at the valgrind output I think this is what the case is: let say we have three files:

utilities.c        - compiled with -fPIC and used ar and ranlib to create utilities.a.
dynamicallyloaded.c- compiled with -fPIC and -shared and linked with utlities.a to generate dynamicallyloaded.so 
main.c             - compiled with -fPIC and linked with utilities.a to create main. main dynamically loads and uses dynamicallyloaded.so .
utilities.h        - delclared a class IfTrackerFile with AubFileName as a static string member like   static string          AubFileName;

utilities.cpp      - defines the static variable: string IfTrackerFile::AubFileName;

valgrind out says that there was invalid free/delete/delete on the line : string IfTrackerFile::AubFileName;

i have no clue what's going on. truly appreciate any help/direction in this regard.

Answer 1

This is a shot in the dark but the issue could be global objects. Instantiating a class as a global variable means that the variable is instantiated before main() is called. This means the constructor is called before main() starts and the destructor is called after main has completed. The order the constructor and destructor are called is also indeterminate.

My advice is to turn all global objects (global variables that are not plain old data - POD - types) into pointer which are instantiated at the beginning of main and destroyed at the end of main.

Answer 2

My guess is that you ended up with two different copies of IfTrackerFile::AubFileName. One by pulling it in directly in your program from utilities.a and another when you dynamically loaded dynamicallyloaded.so. I'm guessing that this confused the system for destructing all static and global objects on program shutdown and you ended up calling a destructor twice.

I don't think you should be mixing .a and .so files in this manner. Basically, a good rule of thumb is to never link a .so file against a .a, even if you put -fPIC code in the .a.