大型可执行文件导致调试器挂起
我有一个大小为 190 MB 的 C++ 二进制文件。当我将此二进制文件放入 dbx 并尝试创建断点时,dbx 挂起。当 dbx 挂起时,我观察到它的内存迅速增长到超过 10 GB。 TotalView 允许我设置断点;然而,它显示的所有数据都是伪造的。我已经成功调试了许多其他较小的二进制文件,所以我的预感是这个二进制文件的大尺寸是问题所在。
二进制:ELF 32 位 MSB 可执行文件 SPARC32PLUS 版本 1,V8+ 必需,动态链接,未剥离。
编译器:CC:Sun C++ 5.9 SunOS_sparc 2007/05/03。
Dbx:7.6 SunOS_sparc 2007/05/03。
总视图:8.2.0-0
操作系统:Solaris 10
我如何使用 Dbx:
dbx mybinary
stop at Something.cc:170
Dbx 永远不会从此命令返回,我最终必须从单独的终端终止 Dbx。
我尝试了一些方法但没有成功:
1. 在大多数库中切换为动态链接,从而将二进制大小减少到 19 MB。
2. 在 Solaris x86 上尝试过。
3. 将软件编译为64位。
有谁知道什么可能导致这种情况发生以及如何解决该问题?
I have a C++ binary that is 190 MB in size. When I put this binary into dbx and try to create a breakpoint, dbx hangs. While dbx is hung, I have observed its memory quickly grow to over 10 GB. TotalView allows me to set breakpoints; however, all the data it displays is bogus. I have successfully debugged many other smaller binaries, so my hunch is the large size of this binary is the problem.
Binary: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped.
Compiler: CC: Sun C++ 5.9 SunOS_sparc 2007/05/03.
Dbx: 7.6 SunOS_sparc 2007/05/03.
TotalView: 8.2.0-0
Operating System: Solaris 10
How I am using Dbx:
dbx mybinary
stop at Something.cc:170
Dbx never returns from this command and I have to eventually kill Dbx from a seperate terminal.
I have tried a few things without success:
1. Switched to linking in most of the libraries dynamically, which reduced the binary size to 19 MB.
2. Tried on Solaris x86.
3. Compiled the software as 64 bit.
Does anyone know what could cause this to happen and how to resolve the issue?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
尝试使用不同的调试器进行调试,以确定是否是您的代码导致了问题。 Solaris 上我最喜欢的调试器是 mdb:
如果您使用 C++ 进行编码,请记住使用损坏的函数名称。您可以通过管道 nm 输出到 grep 来找出您的损坏函数名称是什么:
如果 mdb 与 dbx 存在相同的问题,那么我建议您看一下您的代码。但是,如果 mdb 毫无问题地到达 bp,那么您可以使用 mdb(据我所知,它不能处理源文件),或者您可以继续调整您的应用程序以使 dbx 满意。
Try debugging with a different debugger to determine whether or not your code is causing the issue. My favorite debugger on Solaris is mdb:
Remember to use mangled function names, if you are coding in C++. You pipe nm output to grep to find out what your mangled function name is:
If mdb has the same issue with dbx, then I would suggest that you take a look at your code. If, however, mdb gets to the bp without issues then you can either work with mdb (which cannot, as far as I know, work with source files) or you can keep tweaking your application to make dbx happy.