在 Linux 上，什么会导致 dlopen 发出 SIGFPE？
我有一个来源可疑的库，它被 file 识别为 32 位可执行文件。但是，当我尝试在 32 位 CentOS 4.4 计算机上dlopen 时，dlopen 以 SIGFPE 终止。当然，如果二进制格式有问题，那么 dlopen 应该处理错误吗？
所以问题是：什么样的问题会导致 dlopen 发出 SIGFPE？
I have a library of dubious origins which is identified by file as a 32 bit executable. However, when I try to dlopen it on a 32 bit CentOS 4.4 machine, dlopen terminates with SIGFPE. Surely if there was something wrong with the format of the binary then dlopen should be handling an error?
So the question is: What kinds of problems can cause dlopen to emit SIGFPE?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一些可能的原因是：
此处是关于 GNU 系统中 ELF 格式的哈希生成的有趣讨论，其中当您混合和匹配不是在该发行版/系统上构建的 DSO 时，ABI 不匹配可能会导致系统上出现 SIGFPE。
针对您的可执行文件运行 GDB：
当程序崩溃时，使用以下命令获取回溯
如果堆栈以 do_lookup_x () 结尾，那么您可能会遇到相同的问题，并且应该确保您的 DSO 对于您所在的系统是正确的试图加载它...但是你确实说它有可疑的起源，所以问题可能是类似于所描述的ABI问题。
获取一个可靠的库/可执行文件！ ;)
祝你好运
Some possible reasons are:
Here is an interesting discussion regarding hash generation in the ELF format in GNU systems where an ABI mismatch can cause SIGFPE on systems when you mix and match DSOs not built on that distro/system.
Run GDB against your executable with:
When the program crashes, get a backtrace with
If the stack ends in
do_lookup_x ()then you likely have the same problem and should ensure your DSO is correct for the system you are trying to load it on ... However you do say it has dubious origins so the problem is probably an ABI problem similar to the one described.Get a non-dubious library / executable! ;)
Good Luck