linux共享动态库中同名对象重复析构-两次析构或多次析构引起的double free解决办法

原文链接：http://chengxu.org/p/541.html
Linux 平台下的共享动态库，一般都是通过选项“-fPIC”编译出来。有些应用程序需要链接多个共享库，此时如果在这些共享库中存在相同作用域范围的同名静态成员变量，那么当程序访问完静态成员变量结束析构时，由于内存的 double free 会导致程序 core dump；该问题是由于 Linux 编译器的缺陷造成的，本文就此问题进行深入分析，并指出可以通过新的编译选项“-fPIE”加以解决。
Linux 支持的共享程序库（lib*.so）技术不仅能够有效利用系统资源，而且还对程序设计带来了很大的便利性、通用性等，因此被各种级别的应用系统广泛采用。 动态链接的共享库是在加载应用程序时被加载的，而且它与应用程序是在运行时绑定的：通过动态链接器，将动态共享库映射进应用程序的可执行内存中（动态链接）；在启动应用程序时，动态装载器将所需的共享目标库映射到应用程序的内存（动态装载）。
在通常情况下，共享库都是通过使用附加选项 -fpic 或 -fPIC 进行编译，从目标代码产生位置无关的代码（Position Independent Code，PIC），使用 -shared选项将目标代码放进共享目标库中。位置无关代码需要能够被加载到不同进程的不同地址，并且能得以正确的执行，故其代码要经过特别的编译处理：位置无关代码（PIC）对常量和函数入口地址的操作都是采用基于基寄存器（base register）BASE+ 偏移量的相对地址的寻址方式。即使程序被装载到内存中的不同地址，即 BASE 值不同，而偏移量是不变的，所以程序仍然可以找到正确的入口地址或者常量。
然而，当应用程序链接了多个共享库，如果在这些共享库中，存在相同作用域范围的同名静态成员变量或者同名 ( 非静态 ) 全局变量，那么当程序访问完静态成员变量或全局变量结束析构时，由于某内存块的 double free 会导致 core dump，这是由于 Linux 编译器的缺陷造成的。
如何解决这一问题呢？
这种情况下，如果替换使用选项 -fpie或 -fPIE，来编辑目标可执行程序，该问题就会解决。
这是因为，当使用选项 -fpie或 -fPIE时，生成的共享库不会为静态成员变量或全局变量在 GOT中创建对应的条目（通过 objdump或 readelf命令可以查看，此处不再赘述），从而避免了由于静态对象“构造一次，析构两次”而对同一内存区域释放两次引起的程序 core dump。选项 -fpie和 -fPIE与 -fpic及 -fPIC的用法很相似，区别在于前者总是将生成的位置无关代码看作是属于程序本身，并直接链接进该可执行程序，而非存入全局偏移表 GOT中；这样，对于同名的静态或全局对象的访问，其构造与析构操作将保持一一对应。
通过使用选项 -fpie或 -fPIE代替 -fpic或者 -fPIC，使得生成的共享库不会为静态成员变量或全局变量在 GOT中创建对应的条目，同时也就避免了针对同名静态对象“构造一次，析构两次”的不当操作。