segmentation fault while using dynamically allocated object in shared lib loaded at runtime
I have static library linked to executable file. Executable file itself don't use library symbols. But this executable loads some shared libraries at runtime, one of which uses symbols from library. Below is very simplified version of library source files.
ParentClass.h
#include <iostream>
using namespace std;
class ParentClass {
ParentClass() {}
// some functionality
};
ChildClass.h
#include <ParentClass.h>
struct StaticData {
static const char *staticString;
};
class ChildClass : public ParentClass, public StaticData {
ChildClass() {}
// some extended functionality here
};
ChildClass.cpp
#include "ChildClass.h"
const char * StaticData::staticString = "string";
// functionality implementation
Here is several facts:
1.code like this:
ChildClass test;
//extended use of test functionality
works quite well.
2.code like this:
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)
works quite well when used in binary directly linked with library, but fails with segfault "path_to_exec malloc(): memory corruption: some_address"
when used in shared library loaded in runtime (see description in the beginning).
3.code like this:
ParentClass *test = new ParentClass();
test->some_func();
test->some_other_func();
Works well everywhere.
I'm having trouble understanding why code in item 2 causes segmentation fault, but I am suspecting that trouble is in the use of static data in ChildClass (besides that difference ChildClass only defines some new functions with extended functionality that uses ParenClass functions. Segmentation fault occures even when I am using not overloaded ParentClass functions). But I can't link this single difference with the fact that segnemtation fault occures only while using ChildClass in shared library dynamically loaded to executable my library was linked with.
I'l be glad to hear any ideas to get rid of this seg fault.
Update: bt when using logger function with std::cout (some names are omitted). Call sequence:
ChildClass *test = new ChildClass();
test->printInfo();
test->connect();
connect fnction isn't redefined in 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
Using custom logger:
#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 ???::L开发者_开发技巧ogger::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
Run your program under valgrind (rather than gdb). It will show you the first place where invalid memory access occurs, which may be different from the place where the crash ultimately happens.
Regarding the fact that it's broken when linked as a shared library, are you using -fPIC or not? If not, try it.
精彩评论