使用-static-libstdc++ 构建应用程序和共享库时出现段错误
Seg fault when app & shared lib built with -static-libstdc++
如果我使用 -static-libstdc++ 构建一个 C++ 应用程序，它加载一个共享库（通过 dlopen），该库也是使用 -static-libstdc++ 构建的，那么应用程序段在 dlopen 期间会出错。
但是——这只发生在某些设置中：
- GCC 4.7.4，32 位：通过
- GCC 4.8.3，32 位：通过
- GCC 4.8.4，64 位：通过
- GCC 4.9.2，64 位：通过
- GCC 4.9.3，32 位：失败（除非指定
RTLD_DEEPBIND）
- GCC 4.9.3，64 位：通过
调查结果：
- 如果在构建共享库或应用程序时未使用
-static-libstdc++，它会起作用。
- 如果将 (
RTLD_LAZY | RTLD_DEEPBIND) 传递给 dlopen，它就可以工作。所以我怀疑问题与应用程序和.so. 之间的符号confusion/duplication有关
- 有趣的是，如果我让代码首先使用 (
RTLD_LAZY | RTLD_DEEPBIND) 加载 .so，然后关闭它并仅使用 RTLD_LAZY 重新加载，它也可以工作。
重现步骤
代码：
functions.cpp
extern "C"
{
int ExportedFunction1()
{
std::cout << "\n---\n" << __FUNCTION__ << "\n---\n" << std::endl;
return(0);
}
}
main.cpp
#include <iostream>
#include <dlfcn.h>
int main(int argc, char * argv[])
{
void * ph(NULL);
if(argc == 2 && argv[1][0] == '1')
{
std::cout << "Calling dlopen with flags RTLD_LAZY | RTLD_DEEPBIND..." << std::flush;
ph = dlopen("./libfunctions.so", RTLD_LAZY | RTLD_DEEPBIND);
std::cout << "done. Result: " << ph << std::endl;
if(ph)
dlclose(ph);
}
std::cout << "Calling dlopen with flags RTLD_LAZY..." << std::flush;
ph = dlopen("./libfunctions.so", RTLD_LAZY);
std::cout << "done. Result: " << ph << std::endl;
if(ph)
dlclose(ph);
return 0;
}
建造
$ g++ -m32 -g -fPIC -c functions.cpp -o functions.o
$ g++ -m32 -g -fPIC -shared -Wl,-soname,libfunctions.so -static-libgcc -static-libstdc++ functions.o -o libfunctions.so
$ g++ -m32 -g -fPIC -static-libgcc -static-libstdc++ main.cpp -l dl -o main
运行
$ ./main
Calling dlopen with flags RTLD_LAZY...Segmentation fault (core dumped)
回溯
$ gdb -c ./core ./main
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...done.
[New LWP 19846]
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `./main'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __atomic_add_single (__val=1, __mem=0x0)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/ext/atomicity.h:74
74 { *__mem += __val; }
(gdb) bt
#0 __atomic_add_single (__val=1, __mem=0x0)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/ext/atomicity.h:74
#1 __atomic_add_dispatch (__val=1, __mem=0x0)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/ext/atomicity.h:98
#2 _M_add_reference (this=0x0)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/bits/locale_classes.h:510
#3 std::locale::locale (this=0xb74f7ffc <__gnu_internal::buf_cout_sync+28>)
at /home/test/dev/3rdParty/gcc/gcc-4.9.3/libstdc++-v3/src/c++98/locale_init.cc:223
#4 0xb746f559 in basic_streambuf (this=<optimized out>)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/streambuf:466
#5 stdio_sync_filebuf (__f=0xb76a2a20 <_IO_2_1_stdout_>, this=<optimized out>)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/ext/stdio_sync_filebuf.h:77
#6 std::ios_base::Init::Init (this=0xb74f7a01 <std::__ioinit>)
at /home/test/dev/3rdParty/gcc/gcc-4.9.3/libstdc++-v3/src/c++98/ios_init.cc:85
#7 0xb7469419 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at /home/test/dev/3rdParty/build_toolchain/include/c++/4.9.3/iostream:74
#8 0xb7469456 in _GLOBAL__sub_I_functions.cpp(void) () at functions.cpp:12
#9 0xb772c25e in ?? () from /lib/ld-linux.so.2
#10 0xb772c35a in ?? () from /lib/ld-linux.so.2
#11 0xb7730622 in ?? () from /lib/ld-linux.so.2
#12 0xb772c117 in ?? () from /lib/ld-linux.so.2
#13 0xb772fdf4 in ?? () from /lib/ld-linux.so.2
#14 0xb76edcae in ?? () from /lib/libdl.so.2
#15 0xb772c117 in ?? () from /lib/ld-linux.so.2
#16 0xb76ee3b6 in ?? () from /lib/libdl.so.2
#17 0xb76edd61 in dlopen () from /lib/libdl.so.2
#18 0x0804e102 in main (argc=1, argv=0xbfadc254) at main.cpp:18
令我感到奇怪的是，这似乎只在某些版本的 GCC 中失败，并且仅适用于 32 位。我还没有尝试过 GCC 5。
我很感激thoughts/suggestions。
If -static-libstdc++ is not used when building for either the shared lib or the app, it works.
一般来说，您应该或避免使用-static-libstdc++、或隐藏其所有符号以避免此类问题。
So I suspect the problem is related to symbol confusion/duplication between the app & .so.
正确。特别是，问题在于某些符号是重复的，而另一些则不是。由于这个原因，我们不得不 disable STB_GNU_UNIQUE 个符号。
if I have the code load the .so first with (RTLD_LAZY | RTLD_DEEPBIND), and then close it and re-load with only RTLD_LAZY, it also works.
那是因为 dlclose 如果您使用它实际上不会卸载库。来自 man dlclose:
The function dlclose() decrements the reference count on the dynamic
library handle handle. If the reference count drops to zero and no
other loaded libraries use symbols in it, then the dynamic library
is unloaded.
您应该能够通过在 dlclose 之后停止 GDB 中的程序并查看其 /proc/$PID/maps 来验证是否属于这种情况——您很可能会发现 libfunctions.so 仍然存在于内存中。
如果我使用 -static-libstdc++ 构建一个 C++ 应用程序，它加载一个共享库（通过 dlopen），该库也是使用 -static-libstdc++ 构建的，那么应用程序段在 dlopen 期间会出错。
但是——这只发生在某些设置中：
- GCC 4.7.4，32 位：通过
- GCC 4.8.3，32 位：通过
- GCC 4.8.4，64 位：通过
- GCC 4.9.2，64 位：通过
- GCC 4.9.3，32 位：失败（除非指定
RTLD_DEEPBIND） - GCC 4.9.3，64 位：通过
调查结果：
- 如果在构建共享库或应用程序时未使用
-static-libstdc++，它会起作用。 - 如果将 (
RTLD_LAZY | RTLD_DEEPBIND) 传递给 dlopen，它就可以工作。所以我怀疑问题与应用程序和.so. 之间的符号confusion/duplication有关
- 有趣的是，如果我让代码首先使用 (
RTLD_LAZY | RTLD_DEEPBIND) 加载 .so，然后关闭它并仅使用RTLD_LAZY重新加载，它也可以工作。
重现步骤
代码：
functions.cpp
extern "C"
{
int ExportedFunction1()
{
std::cout << "\n---\n" << __FUNCTION__ << "\n---\n" << std::endl;
return(0);
}
}
main.cpp
#include <iostream>
#include <dlfcn.h>
int main(int argc, char * argv[])
{
void * ph(NULL);
if(argc == 2 && argv[1][0] == '1')
{
std::cout << "Calling dlopen with flags RTLD_LAZY | RTLD_DEEPBIND..." << std::flush;
ph = dlopen("./libfunctions.so", RTLD_LAZY | RTLD_DEEPBIND);
std::cout << "done. Result: " << ph << std::endl;
if(ph)
dlclose(ph);
}
std::cout << "Calling dlopen with flags RTLD_LAZY..." << std::flush;
ph = dlopen("./libfunctions.so", RTLD_LAZY);
std::cout << "done. Result: " << ph << std::endl;
if(ph)
dlclose(ph);
return 0;
}
建造
$ g++ -m32 -g -fPIC -c functions.cpp -o functions.o
$ g++ -m32 -g -fPIC -shared -Wl,-soname,libfunctions.so -static-libgcc -static-libstdc++ functions.o -o libfunctions.so
$ g++ -m32 -g -fPIC -static-libgcc -static-libstdc++ main.cpp -l dl -o main
运行
$ ./main
Calling dlopen with flags RTLD_LAZY...Segmentation fault (core dumped)
回溯
$ gdb -c ./core ./main
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...done.
[New LWP 19846]
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `./main'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __atomic_add_single (__val=1, __mem=0x0)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/ext/atomicity.h:74
74 { *__mem += __val; }
(gdb) bt
#0 __atomic_add_single (__val=1, __mem=0x0)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/ext/atomicity.h:74
#1 __atomic_add_dispatch (__val=1, __mem=0x0)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/ext/atomicity.h:98
#2 _M_add_reference (this=0x0)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/bits/locale_classes.h:510
#3 std::locale::locale (this=0xb74f7ffc <__gnu_internal::buf_cout_sync+28>)
at /home/test/dev/3rdParty/gcc/gcc-4.9.3/libstdc++-v3/src/c++98/locale_init.cc:223
#4 0xb746f559 in basic_streambuf (this=<optimized out>)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/streambuf:466
#5 stdio_sync_filebuf (__f=0xb76a2a20 <_IO_2_1_stdout_>, this=<optimized out>)
at /home/test/dev/3rdParty/gcc/build/i686-pc-linux-gnu/libstdc++-v3/include/ext/stdio_sync_filebuf.h:77
#6 std::ios_base::Init::Init (this=0xb74f7a01 <std::__ioinit>)
at /home/test/dev/3rdParty/gcc/gcc-4.9.3/libstdc++-v3/src/c++98/ios_init.cc:85
#7 0xb7469419 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at /home/test/dev/3rdParty/build_toolchain/include/c++/4.9.3/iostream:74
#8 0xb7469456 in _GLOBAL__sub_I_functions.cpp(void) () at functions.cpp:12
#9 0xb772c25e in ?? () from /lib/ld-linux.so.2
#10 0xb772c35a in ?? () from /lib/ld-linux.so.2
#11 0xb7730622 in ?? () from /lib/ld-linux.so.2
#12 0xb772c117 in ?? () from /lib/ld-linux.so.2
#13 0xb772fdf4 in ?? () from /lib/ld-linux.so.2
#14 0xb76edcae in ?? () from /lib/libdl.so.2
#15 0xb772c117 in ?? () from /lib/ld-linux.so.2
#16 0xb76ee3b6 in ?? () from /lib/libdl.so.2
#17 0xb76edd61 in dlopen () from /lib/libdl.so.2
#18 0x0804e102 in main (argc=1, argv=0xbfadc254) at main.cpp:18
令我感到奇怪的是，这似乎只在某些版本的 GCC 中失败，并且仅适用于 32 位。我还没有尝试过 GCC 5。
我很感激thoughts/suggestions。
If -static-libstdc++ is not used when building for either the shared lib or the app, it works.
一般来说，您应该或避免使用-static-libstdc++、或隐藏其所有符号以避免此类问题。
So I suspect the problem is related to symbol confusion/duplication between the app & .so.
正确。特别是，问题在于某些符号是重复的，而另一些则不是。由于这个原因，我们不得不 disable STB_GNU_UNIQUE 个符号。
if I have the code load the .so first with (RTLD_LAZY | RTLD_DEEPBIND), and then close it and re-load with only RTLD_LAZY, it also works.
那是因为 dlclose 如果您使用它实际上不会卸载库。来自 man dlclose:
The function dlclose() decrements the reference count on the dynamic
library handle handle. If the reference count drops to zero and no
other loaded libraries use symbols in it, then the dynamic library
is unloaded.
您应该能够通过在 dlclose 之后停止 GDB 中的程序并查看其 /proc/$PID/maps 来验证是否属于这种情况——您很可能会发现 libfunctions.so 仍然存在于内存中。