nic*_*2k3 1 c++ memory-management shared-libraries segmentation-fault
我有一个共享库(即libXXX.so)与cpp/h文件关联.它们包含许多函数指针(指向.so函数入口点)和一个用于将此函数包装为所述类的方法的类.
即:.h文件:
typedef void* handle;
/* wrapper functions */
handle okUsbFrontPanel_Construct();
void okUsbFrontPanel_Destruct(handle hnd);
/* wrapper class */
class okCUsbFrontPanel
{
public:
handle h;
public:
okCUsbFrontPanel();
~okCUsbFrontPanel();
};
.cpp文件
/* class methods */
okCUsbFrontPanel::okCUsbFrontPanel()
{ h=okUsbFrontPanel_Construct(); }
okCUsbFrontPanel::~okCUsbFrontPanel()
{ okUsbFrontPanel_Destruct(h); }
/* function pointers */
typedef handle (*OKUSBFRONTPANEL_CONSTRUCT_FN) (void);
typedef void (*OKUSBFRONTPANEL_DESTRUCT_FN) (handle);
OKUSBFRONTPANEL_CONSTRUCT_FN _okUsbFrontPanel_Construct = NULL;
OKUSBFRONTPANEL_DESTRUCT_FN _okUsbFrontPanel_Destruct = NULL;
/* load lib function */
Bool LoadLib(char *libname){
void *hLib = dlopen(libname, RTLD_NOW);
if(hLib){
_okUsbFrontPanel_Construct = ( OKUSBFRONTPANEL_CONSTRUCT_FN ) dlsym(hLib, "okUsbFrontPanel_Construct");
_okUsbFrontPanel_Destruct = ( OKUSBFRONTPANEL_DESTRUCT_FN ) dlsym( hLib, "okUsbFrontPanel_Destruct" );
}
}
/* construct function */
handle okUsbFrontPanel_Construct(){
if (_okUsbFrontPanel_Construct){
handle h = (*_okUsbFrontPanel_Construct)(); //calls function pointer
return h;
}
return(NULL);
}
void okUsbFrontPanel_Destruct(handle hnd)
{
if (_okUsbFrontPanel_Destruct)
(*_okUsbFrontPanel_Destruct)(hnd);
}
然后我有另一个共享库(由我自己制作),它调用:
LoadLib("libXXX.so");
okCusbFrontPanel *device = new okCusbFrontPanel();
导致分段错误.分段错误似乎发生在
handle h = (*_okUsbFrontPanel_Construct)();
但有一种奇怪的行为:一旦我到达
(*_okUsbFrontPanel_Construct)();
我得到了okUsbFrontPanel_Construct()的递归.
有谁有想法吗？
编辑:这是一个使用gdb运行获得的回溯.
#0 0x007590b0 in _IO_new_do_write () from /lib/tls/libc.so.6
#1 0x00759bb8 in _IO_new_file_overflow () from /lib/tls/libc.so.6
#2 0x0075a83d in _IO_new_file_xsputn () from /lib/tls/libc.so.6
#3 0x00736db7 in vfprintf () from /lib/tls/libc.so.6
#4 0x0073ecd0 in printf () from /lib/tls/libc.so.6
#5 0x02cb68ca in okCUsbFrontPanel (this=0x9d0ae28) at okFrontPanelDLL.cpp:167
#6 0x03cac343 in okUsbFrontPanel_Construct () from /opt/atlas/tdaq/tdaq-02-00-00/installed/i686-slc4-gcc34-dbg/lib/libokFrontPanel.so
#7 0x02cb8f36 in okUsbFrontPanel_Construct () at okFrontPanelDLL.cpp:1107
#8 0x02cb68db in okCUsbFrontPanel (this=0x9d0ade8) at okFrontPanelDLL.cpp:169
#9 0x03cac343 in okUsbFrontPanel_Construct () from /opt/atlas/tdaq/tdaq-02-00-00/installed/i686-slc4-gcc34-dbg/lib/libokFrontPanel.so
#10 0x02cb8f36 in okUsbFrontPanel_Construct () at okFrontPanelDLL.cpp:1107
#11 0x02cb68db in okCUsbFrontPanel (this=0x9d0ada8) at okFrontPanelDLL.cpp:169
#12 0x03cac343 in okUsbFrontPanel_Construct () from /opt/atlas/tdaq/tdaq-02-00-00/installed/i686-slc4-gcc34-dbg/lib/libokFrontPanel.so
#13 0x02cb8f36 in okUsbFrontPanel_Construct () at okFrontPanelDLL.cpp:1107
等等...恕我直言因为某种堆栈溢出而得到一个段故障.有太多的递归调用,出了点问题..
顺便说一句,我在使用Scientific Linux 4发行版(基于RH4).
EDIT2:
对于函数okUsbFrontPanel_Construct输出的libokFrontPanel.so的objdump:
00009316 <okUsbFrontPanel_Construct>:
9316: 55 push ebp
9317: 89 e5 mov ebp,esp
9319: 56 push esi
931a: 53 push ebx
931b: 83 ec 30 sub esp,0x30
931e: e8 44 f4 ff ff call 8767 <__i686.get_pc_thunk.bx>
9323: 81 c3 dd bd 00 00 add ebx,0xbddd
9329: c7 04 24 38 00 00 00 mov DWORD PTR [esp],0x38
9330: e8 93 ec ff ff call 7fc8 <_Znwj@plt>
9335: 89 45 e4 mov DWORD PTR [ebp-28],eax
9338: 8b 45 e4 mov eax,DWORD PTR [ebp-28]
933b: 89 04 24 mov DWORD PTR [esp],eax
933e: e8 65 ed ff ff call 80a8 <_ZN16okCUsbFrontPanelC1Ev@plt>
9343: 8b 45 e4 mov eax,DWORD PTR [ebp-28]
9346: 89 45 f4 mov DWORD PTR [ebp-12],eax
9349: 8b 45 f4 mov eax,DWORD PTR [ebp-12]
934c: 89 45 e0 mov DWORD PTR [ebp-32],eax
934f: eb 1f jmp 9370 <okUsbFrontPanel_Construct+0x5a>
9351: 89 45 dc mov DWORD PTR [ebp-36],eax
9354: 8b 75 dc mov esi,DWORD PTR [ebp-36]
9357: 8b 45 e4 mov eax,DWORD PTR [ebp-28]
935a: 89 04 24 mov DWORD PTR [esp],eax
935d: e8 d6 f2 ff ff call 8638 <_ZdlPv@plt>
9362: 89 75 dc mov DWORD PTR [ebp-36],esi
9365: 8b 45 dc mov eax,DWORD PTR [ebp-36]
9368: 89 04 24 mov DWORD PTR [esp],eax
936b: e8 a8 f0 ff ff call 8418 <_Unwind_Resume@plt>
9370: 8b 45 e0 mov eax,DWORD PTR [ebp-32]
9373: 83 c4 30 add esp,0x30
9376: 5b pop ebx
9377: 5e pop esi
9378: 5d pop ebp
9379: c3 ret
在933e确实有一个对<_ZN16okCUsbFrontPanelC1Ev @ plt>的调用.这个调用是否与我的.cpp中的那个混淆了？
既然您已经发布了GDB输出,那么就可以清楚地知道您的问题是什么了.
您所定义的相同的符号libokFrontPanel.so,并在libLoadLibrary.so(缺乏一个更好的名字-它是如此更容易解释的事情时,他们都是正确的),并且这是导致无限递归.
默认情况下,在UNIX上(与Windows不同)来自所有共享库(以及主可执行文件)的所有全局符号都会进入单个"加载程序符号名称空间".
别的不说,这意味着,如果你定义malloc在主可执行文件,这 malloc将被所有的共享库调用,包括libc(即使libc有自己的malloc定义).
所以,这是正在发生的事情:在libLoadLibrary.so你定义的okCUsbFrontPanel构造函数中.我断言还有一个确切符号的定义libokFrontPanel.so.对此构造函数的所有调用(默认情况下)都转到第一个定义(动态加载程序首次观察到的定义),即使创建者libokFrontPanel.so并不打算这样做.循环是(按照相同的顺序GDB打印它们 - 顶部的最里面的框架):
#1 okCUsbFrontPanel () at okFrontPanelDLL.cpp:169
#3 okUsbFrontPanel_Construct () from libokFrontPanel.so
#2 okUsbFrontPanel_Construct () at okFrontPanelDLL.cpp:1107
#1 okCUsbFrontPanel () at okFrontPanelDLL.cpp:169
对构造函数的调用#3旨在转到符号#4 - 内部okCUsbFrontPanel构造函数.相反,它转到了之前看到的定义:你"抢占"符号#4,从而形成一个无限递归循环. libokFrontPanel.solibLoadLibrary.so
道德:除非您了解运行时加载程序决定哪些符号引用绑定到哪些定义的规则,否则不要在多个库中定义相同的符号.
编辑:回答问题的"EDIT2":
是的,对_ZN16okCUsbFrontPanelC1Evfrom 的调用okUsbFrontPanel_Construct将转到你方法中的那个方法的定义okFrontPanelDLL.cpp.检查可能很有启发性objdump -d okFrontPanelDLL.o