3
我有一個可疑來源庫,它被file
識別爲32位可執行文件。但是,當我嘗試在32位CentOS 4.4機器上嘗試dlopen
時,dlopen終止於SIGFPE
。當然,如果二進制格式有問題,那麼dlopen
應該處理錯誤?在linux上,什麼會導致dlopen發出SIGFPE?
所以問題是:什麼樣的問題可以導致dlopen發出SIGFPE?
我有一個可疑來源庫,它被file
識別爲32位可執行文件。但是,當我嘗試在32位CentOS 4.4機器上嘗試dlopen
時,dlopen終止於SIGFPE
。當然,如果二進制格式有問題,那麼dlopen
應該處理錯誤?在linux上,什麼會導致dlopen發出SIGFPE?
所以問題是:什麼樣的問題可以導致dlopen發出SIGFPE?
一些可能的原因是:
Here是關於哈希生成在GNU系統中的ELF格式,其中一個ABI不匹配可以在系統中引起SIGFPE當你混搭DSO的不是那號發行/系統上的一個有趣的討論。
運行GDB對您的可執行文件:
]$ gdb ./my_executable
(gdb) run
當程序崩潰時,得到一個回溯與
(gdb) bt
如果堆棧中do_lookup_x()
結束,那麼你很可能有同樣的問題,並應確保你的DSO對於你試圖加載它的系統是正確的...但是你確實說它有可疑來源所以這個問題可能是一個類似於描述的ABI問題。
獲取非可疑的庫/可執行文件! ;)
好運
莫大的聯繫,謝謝。 我的問題是庫已經在64位RHEL5機器上交叉編譯,我試圖在32位RHEL4機器上運行。魔術技巧是在RHEL 5機器上重建庫時使用「-m32 -Wl, - hash-style = both」。 – kdt 2010-04-23 12:34:35
@kdt - 很高興聽到您解決它! – 2010-04-23 14:57:52