我有一个可疑来源的库,该库由文件标识为32位可执行文件.但是,当我尝试在32位CentOS 4.4机器上dlopen时,dlopen以SIGFPE终止.当然,如果二进制格式存在问题,则dlopen应该处理错误？
因此问题是：哪些类型的问题可能导致dlopen发出SIGFPE？
解决方法:
一些可能的原因是：
>除以零(用gdb排除)
>体系结构不匹配(您是在同一体系结构上自己编译DSO还是预先构建的？)
> ABI兼容性问题(将为一个Linux发行版构建的DSO加载到另一个Linux发行版上).
Here是有关GNU系统中ELF格式的哈希生成的有趣讨论,其中当您混合并匹配不在该发行版/系统上构建的DSO时,ABI不匹配会导致系统上的SIGFPE.
使用以下命令对您的可执行文件运行GDB：
]$gdb ./my_executable
(gdb) run
程序崩溃时,使用以下命令进行回溯
(gdb) bt
如果堆栈以do_lookup_x()结尾,那么您可能会遇到相同的问题,并应确保您的DSO对于要在其上加载的系统是正确的…但是您确实说它的来源可疑,因此问题可能是ABI问题类似于所描述的.
获取一个非可疑的库/可执行文件！
标签：dlopen,sigfpe,linux 来源： https://codeday.me/bug/20191024/1918026.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。