c++ linux双重销毁静态变量。链接符号重叠

Posted 2023-02-21

【中文标题】c++ linux双重销毁静态变量。链接符号重叠

【英文标题】：c++ linux double destruction of static variable. linking symbols overlap

【发布时间】：2011-07-15 23:02:36

【问题描述】：

环境：linux x64，编译器gcc 4.x

项目结构如下：

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

在程序结束时，“sobj”被破坏了两次。这种行为是预期的，但它在同一个内存地址被破坏两次，即析构函数中的相同“this” - 结果存在双重破坏问题。 我认为这是由于某些符号重叠。

该冲突的解决方案是什么？也许一些链接选项？

---

这里是测试用例：

---

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 )

---

该示例在 Windows 上运行正常，但在 linux 上 - 存在问题。 由于它在 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

【问题讨论】：

你确定你不只是delete两个指向同一个对象的指针吗？奥卡姆剃刀建议这就是问题所在。

您能否提供说明问题的经典“最小可编译示例”？

我 100% 确定您将其删除两次 - 我从未听说过“符号重叠”。检查您的代码。

没有代码我们只能猜测（英文描述永远不准确）。产生一些代码和指令来编译它来演示问题。

我提供了示例。乔希，你还 100% 确定吗？？

【参考方案1】：

TL;DR：您不应该将一个库链接一次作为静态依赖项和一次作为动态依赖项。

---

静态变量的析构函数在 Itanium ABI 中是如何执行的（被clang、gcc、icc...使用）？

C++ 标准库提供了一种标准工​​具，用于在程序关闭期间（在 main 结束后）以atexit 的格式安排函数的执行。

行为比较简单，atexit 基本上构建了一个回调堆栈，因此会按照它们调度的reverse顺序执行它们。

每当构造一个静态变量时，在其构造结束后立即在atexit堆栈中注册一个回调以在关闭期间将其销毁。

---

当静态变量同时存在在静态链接库和动态链接库中时会发生什么？

它尝试存在两次。

每个库都会有：

为变量保留的内存区域，由相应的符号（变量的错位名称）指向， 加载部分中的一个条目，用于构建变量并安排其销毁。

令人惊讶的是符号解析在加载器中的工作方式。本质上，加载器在符号和位置（指针）之间建立映射，先到先得。

但是，加载/卸载部分是无名的，因此它们中的每一个都是完整执行的。

因此：

静态变量是第一次构造的， 静态变量第二次构造在第一次之上（已泄露）， 静态变量第一次被破坏， 静态变量被第二次破坏；这通常是检测到问题的地方。

---

那又怎样？

解决方案很简单：不链接到静态库 A（直接）和动态库 B 也链接到 A（动态或静态）。

根据用例，您可以：

静态链接到 B， 动态链接 A 和 B。

---

由于它在 Windows 上运行良好，解决方案应该是更改一些链接选项或类似的东西，但不更改项目结构或不使用静态变量。

万一您确实需要静态变量的两个独立实例，除了重构代码之外，还可以在动态库中隐藏符号。

此 Windows 的默认行为，这就是为什么这里需要 DLLExport 属性，以及为什么因为 CTest::test 忘记了它，所以 Windows 上的行为是不同的。

但是请注意，如果您选择这种行为，该项目的任何未来维护者都会大声诅咒您。没有人希望静态变量有多个实例。

【讨论】：

我知道这是一个旧帖子，但是如果您正在寻找最好的帖子，那么这是您应该寻找的帖子，而不是一个所有者接受的帖子。此外，this post 有几个很好的参考资料可以帮助更好地理解这个问题。

【参考方案2】：

好的，我找到了解决方案：

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

例如如果改变

static CTest test;

到

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

问题将消失。 Linux：

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

修复前的nm输出为：

0000000000200dd4 B _ZN5CTest4testE

修复后：

0000000000200d7c b _ZN5CTest4testE

区别是将全局符号“B”改为局部符号“b”。

可以使用编译器选项“-fvisibility=hidden”，而不是向符号添加“attribute ((visibility ("hidden")))”。该选项使 gcc 的行为更像 Windows 环境。

【参考方案3】：

顺便说一句，如果在函数 stat_useStatic 中定义静态 var，它将只是 linux 中整个程序中该静态 var 的一个实例（但在 Windows 中是两个实例）——这就是我们用于解决该问题的方法。 以下是变化

void stat_useStatic()

    static CTest stest;
    stest.use();
    CTest::test.use();



DLLExport void din_useStatic()

    stat_useStatic();
    CTest::test.use();

现在，Linux 和 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

如你所见，linux只创建一个静态变量，而windows创建两个实例。

真的，看起来linux不应该在第一种情况下双重创建和双重破坏静态变量，按照它的逻辑，与第二种情况相同（函数内部的静态变量）。

使用函数本地静态变量而不是类静态只是解决方法，而不是真正的解决方案。因为库源可能不可用。

【参考方案4】：

没有看到任何代码很难说，但这个领域（动态加载的库）确实没有被标准明确涵盖，因此不同的实现很可能会以不同的方式处理side case。

难道你不能避免这种混淆，例如为静态库的两个实例使用不同的命名空间（例如，通过使命名空间用于由命令行选项定义的静态对象）？

【讨论】：

这里是示例。您的意思是多次编译静态库，使用不同的命名空间？

是的。如果您将命名空间放在编译时参数中（例如 g++ -D... 选项），那么您可以使用命名空间编译动态加载的静态库中使用的静态库，并将可执行文件中与另一个命名空间链接的静态库编译。这样，两个对象将是不同的，而无需更改源代码中的用法。

我也想过这个解决方案，但它是不可接受的——它只是一种解决方法。如果静态库没有代码，即来自某个外部项目怎么办？由于项目在 Windows 中运行良好，我认为它应该是 linux 的良好解决方案