c++ - 在运行时加载的共享库中使用动态分配的对象时出现段错误

Question

我有链接到可执行文件的静态库。可执行文件本身不使用库符号。但是这个可执行文件在运行时加载了一些共享库，其中一个使用了库中的符号。下面是非常简化的库源文件版本。

父类.h

#include <iostream>

using namespace std;

class ParentClass {
  ParentClass() {}

 // some functionality
 };

子类.h

#include <ParentClass.h>

struct StaticData {
  static const char *staticString;
};

class ChildClass : public ParentClass, public StaticData {
  ChildClass() {}
  // some extended functionality here
};

子类.cpp

#include "ChildClass.h"

const char * StaticData::staticString = "string";

// functionality implementation

这里有几个事实:

1.代码如下:

ChildClass test;

//extended use of test functionality

效果很好。

2.代码如下:

 ChieldClass *test = new ChieldClass();
    test->some_func(); // some func don't use dynamic memory
    test->some_other_func(); // dynamic memory used (in my case malloc in gethostbyname system function)

在与库直接链接的二进制文件中使用时效果很好，但在运行时加载的共享库中使用时出现段错误 "path_to_exec malloc(): memory corruption: some_address" 失败(参见开始)。

3.代码如下:

ParentClass *test = new ParentClass();
test->some_func();
test->some_other_func();

无处不在。

我无法理解为什么第 2 项中的代码会导致段错误，但我怀疑问题出在 ChildClass 中使用静态数据(除此之外，ChildClass 仅定义了一些具有使用 ParenClass 函数的扩展功能的新函数. 即使在我使用未重载的 ParentClass 函数时也会发生段错误)。但是我无法将这一单一差异与以下事实联系起来:仅在共享库中使用 ChildClass 时才会发生段错误，而共享库动态加载到我的库所链接的可执行文件中。

我很高兴听到任何消除此段错误的想法。

更新:bt 当使用带有 std::cout 的记录器函数时(省略了一些名称)。调用顺序:

ChildClass *test = new ChildClass();
test->printInfo();
test->connect();

连接函数没有在 ChildClass 中重新定义。

(gdb) bt
#0  0x00007f756f67e165 in raise () from /lib/libc.so.6
#1  0x00007f756f680f70 in abort () from /lib/libc.so.6
#2  0x00007f756f6b427b in ?? () from /lib/libc.so.6
#3  0x00007f756f6bdad6 in ?? () from /lib/libc.so.6
#4  0x00007f756f6c0b6d in ?? () from /lib/libc.so.6
#5  0x00007f756f6c2930 in malloc () from /lib/libc.so.6
#6  0x00007f756f6af35b in ?? () from /lib/libc.so.6
#7  0x00007f756f7291de in ?? () from /lib/libc.so.6
#8  0x00007f756f72aa65 in __res_maybe_init () from /lib/libc.so.6
#9  0x00007f756f72ca70 in __nss_hostname_digits_dots () from /lib/libc.so.6
#10 0x00007f756f731fe4 in gethostbyname_r () from /lib/libc.so.6
#11 0x0000000000507929 in underlaying_c_code_connect (client=0x7f7564017348) at /home/beduin/???/lib/???/UnderlayingCCode.cpp:1477
#12 0x0000000000504a24 in ParentClass::connect (this=0x7f7564017340) at /home/beduin/???/lib/???/ParentClass.cpp:216
#13 0x00007f7569342f68 in Plugin::Start (this=0x7f75640208c0) at /home/beduin/???/plugins/???/Plugin.cpp:84
#14 0x00000000004c7d45 in ???::PluginHolder::StartPlugin (this=0x7fffed7dc5e0, it=@0x7fffed7dbad0) at /home/beduin/???/plugins.cpp:317
#15 0x00000000004c8656 in ???::PluginHolder::Start (this=0x7fffed7dc5e0) at /home/beduin/mrvs/framework/base/plugins.cpp:401
#16 0x00000000004c7935 in ???::PluginHolder::LockNLoad (this=0x7fffed7dc5e0) at /home/beduin/???/plugins.cpp:284
#17 0x00000000004afe6f in main (argc=3, argv=0x7fffed7dd978) at /home/beduin/???/main.cpp:148

使用自定义记录器:

#0  0x00007f824aa12165 in raise () from /lib/libc.so.6
#1  0x00007f824aa14f70 in abort () from /lib/libc.so.6
#2  0x00007f824aa4827b in ?? () from /lib/libc.so.6
#3  0x00007f824aa51ad6 in ?? () from /lib/libc.so.6
#4  0x00007f824aa54b6d in ?? () from /lib/libc.so.6
#5  0x00007f824aa56930 in malloc () from /lib/libc.so.6
#6  0x00007f824b2a46bd in operator new () from /usr/lib/libstdc++.so.6
#7  0x00007f824b280b29 in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.6
#8  0x00007f824b281aeb in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.6
#9  0x00007f824b28205c in std::string::reserve () from /usr/lib/libstdc++.so.6
#10 0x00007f824b27c021 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow () from /usr/lib/libstdc++.so.6
#11 0x00007f824b280215 in std::basic_streambuf<char, std::char_traits<char> >::xsputn () from /usr/lib/libstdc++.so.6
#12 0x00007f824b2763b5 in std::__ostream_insert<char, std::char_traits<char> > () from /usr/lib/libstdc++.so.6
#13 0x00007f824b27662f in std::operator<< <std::char_traits<char> > () from /usr/lib/libstdc++.so.6
#14 0x00000000004f4fb0 in ???::Logger::LogWriter::operator<< <char [25]> (this=0x7fff8e241fc0, str=@0x52b2fd)
    at /home/beduin/???/log:184
#15 0x0000000000500388 in ChildClass::printInfo (this=0x7f8240017470) at /home/beduin/???/ChildClass.cpp:480
#16 0x00007f82446d6f5c in Plugin::Start (this=0x7f82400208a0) at /home/beduin/???/plugins/???/Plugin.cpp:83
#17 0x00000000004c7d35 in ???::PluginHolder::StartPlugin (this=0x7fff8e243b30, it=@0x7fff8e243020) at /home/beduin/???/plugins.cpp:317
#18 0x00000000004c8646 in ???::PluginHolder::Start (this=0x7fff8e243b30) at /home/beduin/???/plugins.cpp:401
#19 0x00000000004c7925 in ???::PluginHolder::LockNLoad (this=0x7fff8e243b30) at /home/beduin/???/plugins.cpp:284
#20 0x00000000004afe5f in main (argc=3, argv=0x7fff8e244ec8) at /home/beduin/???/main.cpp:148

Answer 1

在 valgrind(而不是 gdb)下运行你的程序。它会向您显示第一个发生无效内存访问的地方，这可能与最终发生崩溃的地方不同。

关于它作为共享库链接时损坏的事实，您是否使用 -fPIC？如果没有，请尝试。