c++ linux double destruction of static variable. linking symbols overlap

Question

Environment: linux x64, compiler gcc 4.x

Project has following structure:

static library "slib"
-- inside this library, there is static object "sobj"

dynamic library "dlib"
-- links statically "slib"

executable "exe":
-- links "slib" statically
-- links "dlib" dynamically

at end of the program, "sobj" is destructed twice. That behaviour is expected, BUT it is destructed twice at same memory address, i.e. same "this" in destructor - as the result there is double destruction problem. I think it is due some symbol overlapping.

What the solution for that conflict? Maybe some linking option?

---

Here is test case:

---

main_exe.cpp

#include <cstdlib>

#include "static_lib.h"
#include "dynamic_lib.h"

int main(int argc, char *argv[])
{
    stat_useStatic();
    din_useStatic();
    return EXIT_SUCCESS;
}

---

static_lib.h

#ifndef STATIC_LIB_H
#define STATIC_LIB_H

#include <cstdio>

void stat_useStatic();
struct CTest
{
    CTest(): status(isAlive)
    {
        printf("CTest() this=%d\n",this);
    }
    ~CTest()
    {
        printf("~CTest() this=%d, %s\n",this,status==isAlive?"is Alive":"is Dead");
        status=isDead;
    }
    void use()
    {
        printf("use\n");
    }
    static const int isAlive=12385423;
    static const int isDead=6543421;
    int status;

    static CTest test;
};

#endif

---

static_lib.cpp

#include "static_lib.h"

CTest CTest::test;

void stat_useStatic()
{
    CTest::test.use();
}

---

dynamic_lib.h

#ifndef DYNAMIC_LIB_H
#define DYNAMIC_LIB_H

#include "static_lib.h"

#ifdef WIN32
#define DLLExport __declspec(dllexport)
#else
#define DLLExport 
#endif
DLLExport void din_useStatic();


#endif

---

dynamic_lib.cpp

#include "dynamic_lib.h"

DLLExport void din_useStatic()
{
    CTest::test.use();
}

---

CMakeLists.txt

project( StaticProblem )
cmake_minimum_required(VERSION 2.6)
if(WIN32)
else(WIN32)
    ADD_DEFINITIONS(-fPIC)
endif(WIN32)

ADD_LIBRARY( static_lib  STATIC static_lib.cpp static_lib.h)

ADD_LIBRARY( dynamic_lib SHARED dynamic_lib.cpp dynamic_lib.h)
TARGET_LINK_LIBRARIES( dynamic_lib static_lib )

ADD_EXECUTABLE( main_exe main_exe.cpp )
TARGET_LINK_LIBRARIES( main_exe static_lib dynamic_lib )

---

That example works OK, on windows, but on linux - there is problem. As it works ok on windows, solution should be like change some linking option or something like that, but not change project structure or not use static vars.

Output:

Windows

CTest() this=268472624
CTest() this=4231488
use
use
~CTest() this=4231488, is Alive
~CTest() this=268472624, is Alive

Linux

CTest() this=6296204
CTest() this=6296204
use
use
~CTest() this=6296204, is Alive
~CTest() this=6296204, is Dead

Answer 1

TL;DR: you should not link a library once as a static dependency and once as a dynamic dependency.

---

How are the destructors of static variables executed in the Itanium ABI (used by clang, gcc, icc...)?

The C++ Standard Library offers a standard facility to schedule the execution of a function during the program shut-down (after main has ended) in the format of atexit.

The behavior is relatively simple, atexit basically builds a stack of callbacks and will thus execute them in the reverse order of their scheduling.

Whenever a static variable is constructed, immediately after its construction ends, a callback is registered in the atexit stack to destroy it during shutdown.

---

What happens when a static variable exists both in a statically linked library and a dynamically linked library?

It attempts to exist twice.

Each library will have:

• a memory area reserved for the variable, pointed to by the corresponding symbol (the mangled name for the variable),
• an entry in the load section to build the variable, and schedule its destruction.

The surprise comes from the way symbol resolution works in the loader. Essentially, the loader builds up a mapping between symbol and location (pointer), in a first come first serve basis.

However, the load/unload sections are nameless, and therefore each of them is executed in full.

Therefore:

• the static variable is constructed a first time,
• the static variable is constructed a second time over the first one (which is leaked),
• the static variable is destructed a first time,
• the static variable is destructed a second time; which is generally where the problem is detected.

---

So what?

The solution is simple: NOT linking against both a static library A (directly) and a dynamic library B also linking against A (dynamically or statically).

Depending on the use case, you may either:

• link statically against B,
• link dynamically against both A and B.

---

As it works OK on windows, solution should be like change some linking option or something like that, but not change project structure or not use static vars.

In the unlikely event where you really need two independent instances of the static variable, apart from refactoring your code, it is possible to instead hide the symbols in your dynamic library.

This Windows' default behavior, which is why the DLLExport attribute is required there, and why since it was forgotten for CTest::test the behavior on Windows is different.

Do note, however, that any future maintainer of this project will curse you loudly if you opt for this behavior. Nobody expects a static variable to have multiple instances.

Answer 2

Hard to say without seeing any code, but this territory (dynamically loaded libraries) is not indeed explicitly covered by the standard so it's well possible that different implementations will handle side cases differently.

Can't you just avoid this confusion, for example by using different namespaces for the two instances of the static library (e.g. by making the namespace to use for the static object defined by a command line option)?

Answer 3

OK, I have found solution:

http://gcc.gnu.org/wiki/Visibility

For example if change

static CTest test;

to

__attribute__ ((visibility ("hidden"))) static CTest test;

problem will gone. Linux:

CTest() this=-1646158468
CTest() this=6296196
use
use
~CTest() this=6296196, is Alive
~CTest() this=-1646158468, is Alive

nm output before fix was:

0000000000200dd4 B _ZN5CTest4testE

after fix:

0000000000200d7c b _ZN5CTest4testE

Difference is changed global symbol "B" to local symbol "b".

Instead of adding "attribute ((visibility ("hidden")))" to symbols, it is possible to use compiler option "-fvisibility=hidden". That option makes gcc to behave much more like Windows env.

Answer 4

By the way, if define static var inside function stat_useStatic, it will be only one instance of that static var in whole program in linux (but two instance in Windows)- and thats we are using for workaround that problem. Here are changes

void stat_useStatic()
{
    static CTest stest;
    stest.use();
    CTest::test.use();
}


DLLExport void din_useStatic()
{
    stat_useStatic();
    CTest::test.use();
}

Now, behaviour of Linux and Windows differs even more:

Windows

CTest() this=268476728
CTest() this=4235592
CTest() this=4235584
use
use
CTest() this=268476720
use
use
use
~CTest() this=4235584, is Alive
~CTest() this=4235592, is Alive
~CTest() this=268476720, is Alive
~CTest() this=268476728, is Alive

Linux

CTest() this=6296376
CTest() this=6296376
CTest() this=6296392
use
use
use
use
use
~CTest() this=6296392, is Alive
~CTest() this=6296376, is Alive
~CTest() this=6296376, is Dead

As you can see, linux create only one static var, but windows create two instances.

Realy, it looks like linux should not double create and double destruct static var in first case, by it's logic, same as in second case (static var inside func).

Using function local static var's instead of class static is just workaround, not real solution. Because library source can be unavailable.