CODEWITHSUNDEEP
c++debuggingdbxtotalview
Hitman
Hitman

Reputation: 123

Large executable causes debuggers to hang

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?

Upvotes: 4

Views: 508

Answers (1)

Mustafa Ozturk
Mustafa Ozturk

Reputation: 811

Try debugging with a different debugger to determine whether or not your code is causing the issue. My favorite debugger on Solaris is mdb: 

mdb ./yourapplicationname
> your_c_fn_name::bp
> ::run

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:

nm ./yourapplicationname | grep yourc++fnname

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.

Upvotes: 2

Related Questions