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

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


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.


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=-1646158468CTest() this=6296196useuse~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.


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=268476728CTest() this=4235592CTest() this=4235584useuseCTest() this=268476720useuseuse~CTest() this=4235584, is Alive~CTest() this=4235592, is Alive~CTest() this=268476720, is Alive~CTest() this=268476728, is Alive

Linux

CTest() this=6296376CTest() this=6296376CTest() this=6296392useuseuseuseuse~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.