how to get as much as possible from dbx - c++

I do TDD on a daily basis for my C++ development on Solaris10. It has greatly reduced the time I have to spend using my debugger but sometime this is the only option.
DBX is pretty powerful but not that user friendly. Note that I'm talking about console DBX not the SunStudio GUI for DBX).
What are the best productivity tips you can give for dbx C++ debugging?
PS. Changing debugger is not an option.

I have bookmarked a few sites related to dbx. Here they are, in no particular order in case they might be useful to you:
Why Can't dbx Find My Function?
Online Help for the Dbx Debugger
Sun Studio: debugging a multi-threaded application w/ dbx
gdb vs. dbx: commands mapping and feature comparison
Importing debug information into dbx
command line dbx : See more source
Sun Studio C++ - Your .dbxrc (NB: adapt the integer type used to cast pointers according to your pointer size)
Sun Studio: Investigating memory leaks with dbx
Sun Studio: Gathering memory allocations/leaks data, from a running process
EDIT on 2012 july 19th: I've tried to fix several link since Chris Quenelle's blog has moved. Some articles can still be accessed thanks to the wayback machine.

One of the powerful features of dbx is the built in ksh. You can write shell functions that are as complex as you might want to print customized views of data structures, or follow pointers in a specific route. The shell is an old variation of pdksh, so it's not the nicest for programming, but it's much better than not having any built-in language to use. There is also extensive help available from the command line. One trick for searching the help is to use "vi $helpfile" from within the dbx command shell. Tha tedits the raw helpfile data in one large file. You can see some examples of shell functions in the dbxrc file that ships with dbx and is loaded by default. You can see a more sophisticated example by looking at the libumem integration module. You can find it here:
http://quenelle.org/sun%20tech/2007/using-dbx-and-libumem.html

I too have to use dbx at work and understand your frustrations!
A few tips I have discovered which make my life a little easier:
Using the built commands system like this:
when stop { print whatever ; }
Obviously doesn't work when whatever is out of scope, but I find it useful enough. I have yet to have much joy with the 'trace' facility, YMMV.
Making your own .dbxrc file makes life much easier, as does the "pathmap" feature.
Finally, this is only obvious if you know it already, but try Sun's manual.
It isn't particularly well written, but still an essential read.

Thanks to Luc Hermitte! Here is an updated version of his links and a few others.
Why Can't dbx Find My Function?
Sun Studio: debugging a multi-threaded application w/ dbx
Importing debug information into dbx
command line dbx : See more source
Sun Studio: Investigating memory leaks with dbx
Sun Studio: Gathering memory allocations/leaks data, from a running process
Memory Leak Checking with libumem (if you are using dbx you might want to know about libumem)
Using dbx with libumem (substantial dbx script example)
How to use counts with breakpoints
Adding automatic pretty-printers to dbx
Oracle: Getting Started with dbx 12.3
Oracle: dbx Manual 12.2
Additional tips:
dbx has a ksh shell built in, so you can build powerful customized functions.
You can get simple tracing with something like:
when at foo.cc:35 { print varname; }
view all of the online help using: vi $helpfile

Related

Better text UI debugger for C++, like pudb for python

I'm trying to debug a large C++ project on Linux remotely, which is a little difficult to re-build via Visual Studio locally. Therefore I attempt to debug it via console. While, the gdb or gdb --tui or gdb-dashboard tools is not convenient for interaction. I think pudb is a tool for python in the term of interaction. Therefore, are there any better text UI debuggers via console for C++?
Thanks for telling me the tools or any suggestion, I will really appreciate it!
pudb is awesome and you can drop into an IPython terminal at any time with the current local variables. You probably won't get that level of interaction in C++ anytime soon. But gdb is very powerful and using the TUI plus some pretty-printers is definitely very usable, even in larger projects.
It helps if you read the documentation and learn some tricks, such as using gdb's convenience variables. You can store an object in a convenience variable when it is in scope and access it later to check its state using the convenience variable (as long as it still exists).
Using breakpoint commands and a .gdbinit file with repetitive commands also helps a lot.
If you want to implement pretty printers for some of you classes, I think looking at other people's code is a great way to start. Here you can see some pretty printers for some classes in the armadillo library (used for linear algebra).

Find out where application is hanging

Is there a way to figure out where an application is hanging and not completing its function? I opened the call stack but it is empty. What does this mean. Does anyone have any advice for debugging where an application was the moment it started to hang/become non responsive.
Edit: I am using Visual Studio 2010
When this happens to me, I find attaching the Very Sleepy profiler to the debugee often makes it easy to identify where the hang occurred, even if you attach it after it happened - just look for stackframes that were active for 100% of the profiler sampling session (by sorting the list by the "Inclusive %" column and looking at the top).
Compile your application with all warnings enabled and with the compiler producing debugging information. On Linux, that means g++ -Wall -g. Work on the source code till you got no more warnings. Learn to use a debugger (e.g. gdb on Linux), and use its step by step abilities.
But we can't help you more, because this is system dependent and you did not tell what system you are using and you did not show us the code you are debugging.
Read How To Debug Small Programs
In addition to using the debugger, run a profiler through the code. My VS is rather rusty, so I can't give details on how to do so, but google can help.
It would also help to have many small functions instead of few large ones, as the tightest granularity of the profile is function level.
Put log statements into the code. It is time consuming but some sort of divide and conquer approach should help you solve the problem.

Tool for generating a call flow graph [C C++ solaris linux]

I'm quite fond of IDA, but I'm working in Solaris on this project. I do have a linux machine, and if nothing is in the same league as IDA then I'll convince management to purchase a license for it.
Barring that, I'm looking for alternative suggestions. Some of the other features in IDA would be handy, but the main thing I need at the moment is a call flow graph generator not based on source code. If it needs extra output from the build step, that's fine, but some of the libraries I need to look at I don't have source for.
So far, it looks like my best choices are Valgrind's Callgrind, lida, and gprof. Any further suggestions are welcome.
re: gprof, the GNU compiler set provided to us by Windriver is missing some libraries that would normally be supplied with a GNU compiler to provide (among other things) facilities for profiling. It's a good solution to the more general problem, but for now I'm opting to try other solutions first.
edit Some of the Rational tools (Purify, Quantify, etc) might also work well for this. I'm in the same boat as with IDA with that, but I figure someone googling might find the suggestion helpful.
edit2 Valgrind hasn't been ported to solaris/sparc ;p
Take a look at the ERESI Project. It's a reverse engineering framework and it has a tool, called ELFsh, with capabilities of generating CFG from machine code. It doesn't have a stable/final yet, but it's worth a shot.
If you want to try it:
download and install (apt-get on Ubuntu)
run elfsh32. You'll enter a shell.
load your binary: load /bin/bash
analyse it: analyse
generate the graph: graph
You'll get a graph in .dot format and a rendered PNG (this one was too large to post here).
You can generate a call graph with Gprof. It can be visualized with Kprof.
Very late answer but can still be useful.. On Solaris you can use collect.
collect your_program your_args...
It will generate a directory like test.1.er
You can then visualize the call graph on the console with er_print -calltree test.1.er
Or on X-Window with analyser

Windows Application Profilers - C++ Exe

I have a bat script which calls out to an exe and starts this off - I dont know what language it is written in (Probably C++)
I want to find a profiler that allows me to run a command a few times and gathers IO/CPU and other stats
It needs to be open source where possible
Any suggestions
You may try Performance Analysis of Logs (PAL) - http://pal.codeplex.com
It has predefined templates for major system metrics (see System Overview template).
It may automatically create quite impressive report including graphs and brief explanations on detected 'hotspots'.
I have used Glowcode (www.glowcode.com) in the past. It's not open source, but quite easy to use, can profile an executable, and is available on an evaluation basis as well.
I recall it was quite cheap as well.
For Windows, XPERF is your friend, and is a free download.
Check out the Windows Performace Analysis Tools site for more information on this and other tools.
Have fun!

Is there a C++ gdb GUI for Linux? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Briefly: Does anyone know of a GUI for gdb that brings it on par or close to the feature set you get in the more recent version of Visual C++?
In detail: As someone who has spent a lot of time programming in Windows, one of the larger stumbling blocks I've found whenever I have to code C++ in Linux is that debugging anything using commandline gdb takes me several times longer than it does in Visual Studio, and it does not seem to be getting better with practice. Some things are just easier or faster to express graphically.
Specifically, I'm looking for a GUI that:
Handles all the basics like stepping over & into code, watch variables and breakpoints
Understands and can display the contents of complex & nested C++ data types
Doesn't get confused by and preferably can intelligently step through templated code and data structures while displaying relevant information such as the parameter types
Can handle threaded applications and switch between different threads to step through or view the state of
Can handle attaching to an already-started process or reading a core dump, in addition to starting the program up in gdb
If such a program does not exist, then I'd like to hear about experiences people have had with programs that meet at least some of the bullet points.
Does anyone have any recommendations?
Edit:
Listing out the possibilities is great, and I'll take what I can get, but it would be even more helpful if you could include in your responses:
(a) Whether or not you've actually used this GUI and if so, what positive/negative feedback you have about it.
(b) If you know, which of the above-mentioned features are/aren't supported
Lists are easy to come by, sites like this are great because you can get an idea of people's personal experiences with applications.
Eclipse CDT will provide an experience comparable to using Visual Studio. I use Eclipse CDT on a daily basis for writing code and debugging local and remote processes.
If you're not familiar with using an Eclipse based IDE, the GUI will take a little getting used to. However, once you get to understand the GUI ideas that are unique to Eclipse (e.g. a perspective), using the tool becomes a nice experience.
The CDT tooling provides a decent C/C++ indexer that allows you to quickly find references to methods in your code base. It also provides a nice macro expansion tool and limited refactoring support.
With regards to support for debugging, CDT is able to do everything in your list with the exception of reading a core dump (it may support this, but I have never tried to use this feature). Also, my experience with debugging code using templates is limited, so I'm not sure what kind of experience CDT will provide in this regard.
For more information about debugging using Eclipse CDT, you may want to check out these guides:
Interfacing with the CDT debugger, Part 2: Accessing gdb with the Eclipse CDT and MI
CDT Debug Tutorial
gdb -tui works okay if you want something GUI-ish, but still character based.
You won't find anything overlaying GDB which can compete with the raw power of the Visual Studio debugger. It's just too powerful, and it's just too well integrated inside the IDE.
For a Linux alternative, try DDD if free software is your thing.
Check out Nemiver C/C++ Debugger. It is easy to install in Ubuntu (Developer Tools/Debugging).
Update: New link.
Qt Creator seems like good stuff. A colleague showed me one way set it up for debugging:
Create a new project, "Import of Makefile-based Project".
Point it to your root project folder (it will index sources under it, and it is impressively fast).
Go to project settings and add a run configuration, then specify the executable you want to debug, and its arguments.
Qt Creator seems to insist on building your project before debugging it. If you don't want that, or don't use make, just go to projects -> build (Left panel), then, on the right panel in "Build Steps", remove all the steps, including the step by default when you created the project.
That may seem like a bit much work for debugging an app I had already compiled, but it is worth it. The debugger shows threads, stacks and local variables in a similar way to Visual Studio and even uses many of the same keyboard shortcuts. It seems to handle templates well, at least std::string and std::map. Attaching to existing processes and core dumps seems to be supported, though I haven't tested it yet.
Keep in mind that I used it for less than and hour now, but I'm impressed so far.
I loathe the idea of Windows development, but the VC++ debugger is among the best I've seen. I haven't found a GUI front end that comes close to the VC one.
GDB is awesome once you really get used to it. Use it in anger enough and you'll become very proficient. I can whiz around a program doing all the things you listed without much effort anymore. It did take a month or so of suffering over a SSH link to a remote server before I was proficient. I'd never go back though.
DDD is really powerful but it was quite buggy. I found it froze up quite often when it got messages from GDB that it didn't grok. It's good because it has a gdb interface window so you can see what's going on and also interact with gdb directly. DDD can't be used on a remote X session in my environment (a real problem, since I'm sitting at a thin client when I do Unix dev) for some reason so it's out for me.
KDevelop followed typical KDE style and exposed EVERYTHING to the user. I also never had any luck debugging non KDevelop programs in KDevelop.
The Gnat Programming Studio (GPS) is actually quite a good front-end to GDB. It doesn't just manage Ada projects, so it's worth trying out if you are in need of a debugger.
You could use Eclipse, but it's pretty heavy weight and a lot of seasoned Unix people I've worked with (me included) don't care much for its interface, which won't just STFU and get out of your way. Eclipse also seems to take up a lot of space and run like a dog.
I use cgdb, simple and usefull
I use DDD a lot, and it's pretty powerful once you learn to use it. One thing I would say is don't use it over X over the WAN because it seems to do a lot of unnecessary screen updates.
Also, if you're not mated to GDB and don't mind ponying up a little cash, then I would try TotalView. It has a bit of a steep learning curve (it could definitely be more intuitive), but it's the best C++ debugger I've ever used on any platform and can be extended to introspect your objects in custom ways (thus allowing you to view an STL list as an actual list of objects, and not a bunch of confusing internal data members, etc.)
I used KDbg (only works under KDE).
Check out the Eclipse CDT project. It is a plugin for Eclipse geared towards C/C++ development and includes a fairly feature rich debugging perspective (that behind the scenes uses GDB). It is available on a wide variety of platforms.
DDD is the GNU frontend for gdb: http://www.gnu.org/software/ddd/
Similar comfortable to the eclipse gdb frontend is the emacs frontend, tightly tied to the emacs IDE. If you already work with emacs, you will like it:
GDB Emacs Frontend
Qt Creator-on-Linux is certainly on par with Visual Studio-on-Windows for C++ nowadays. I'd even say better on the debugger side.
I've tried a couple of different guis for gdb and have found DDD to be the better of them.
And while I can't comment on other, non-gdb offerings for linux I've used a number of other debuggers on other platforms.
gdb does the majority of the things that you have in your wish list. DDD puts a nicer front on them. For example thread switching is made simpler. Setting breakpoints is as simple as you would expect.
You also get a cli window in case there is something obscure that you want to do.
The one feature of DDD that stands out above any other debugger that I've used is the data "graphing". This allows you to display and arrange structures, objects and memory as draggable boxes. Double clicking a pointer will open up the dereferenced data with visual links back to the parent.
There's one IDE that is missing in this list and which is very efficient (I've used it in many C/C++ projects without any issues): Netbeans.
What can be stepped through is going to be limited by the debugging information that g++ produces, to a large extent. Emacs provides an interface to gdb that lets you control it via the toolbars/menus and display data in separate windows, as well as type gdb commands directly. Eclipse's CDT provides similar tools. I've heard of Anjuta and Code::Blocks but never used them.
As someone familiar with Visual Studio, I've looked at several open source IDE's to replace it, and KDevelop comes the closest IMO to being something that a Visual C++ person can just sit down and start using. When you run the project in debugging mode, it uses gdb but kdevelop pretty much handles the whole thing so that you don't have to know it's gdb; you're just single stepping or assigning watches to variables.
It still isn't as good as the Visual Studio Debugger, unfortunately.
Have you ever taken a look at DS-5 debugger?
There is a paid version which includes a lot of helpful features, but you can also use Community Edition for free (which is also quite useful especially for embedded systems).
I have a positive experience with this tool when debugging Android applications on real device using eclipse.
You don't mention whether you are using Windows or UNIX.
On UNIX systems, KDevelop is good but I use KDbg because it is easy to use and will also work with apps not developed in KDevelop.
Eclipse is good on both platforms.
On Windows, there is a great package called Wascana Desktop Developer which is Eclipse CDT and MinGW all packaged up and preconfigured nicely for the minimum of pain. Its the best thing I've found for developing GNU code on Windows.
I have used all these debuggers and none of them are as good as MS Dev Studio. Eclipse/Wascana is probably the closest but it does have limitations like you cannot step into DLLs and it doesn't do as good a job at examining variables.
The Code:Blocks C++ IDE has a graphical wrapper, with a few of the features you want, but nothing like the power of VS.
VisualGDB is another Visual Studio plugin to develop and debug applications on linux and embedded platforms.
KDevelop works pretty well.
Have you tried gdb -w with cygwin gdb.
It is supossed to have a windows interface which works fairly well.
The only problem I found is that on my present machine it didn't run that way until after I installed ddd. I suspect that it requires tcltk which was installed when I installed ddd.
Latest version of Geany supports it (only on Linux, though)
If you are looking for gdb under Visual Studio, then check WinGDB.
In the last 15 months I use insight (came with FC6). It is not great, it is written in Tcl/Tk, but it is simple and useful. DDD is of similar quality / utility, but somewhat harder to use (various GUI gotchas and omissions). I also tried to integrate gdb with my IDE, SlickEdit. It worked OK (I played some 4 hours with it), but I did not like the GUI context switches. I like my IDE to remain unchanged while I am debugging; on Windows I use SlickEdit for IDE and Visual Studio Debugger for debugging. So from the 3: Insight, DDD and SlickEdit, Insight is my 1st choice, I use it >95% of the time, command-line gdb and DDD make up the other 5%. If I get the chance, I will eval Eclipse at some point, my work PC does not seem to have enough RAM (1GB only) to run Eclipse reasonably well.
I have also heard a lot of praise for TotalView, including 1st hand during a job interview. I obtained an eval for our company in late 2008, but in the end we did not proceed as gdb was good enough for our needs; and it is free and ubiquitous.
Use www.zero-bugs.com/
Zero debugger, it requires C++0x support from gcc
I was searching for a debugger to step through a running programm. Say: Attach. The programm was build with eclipse, but because of maybe some multithreadding obstrucles, no sourcefiles where fond. What ever.
I got very compfortable with NetBeans.
[debug] from menu -> Attach Deugger...
as process chose the one to debug
as project [new project]
Now the window disappars and you see nothing. detach from the process. The Read Square "Stop" helps.
import source from the project as e.g. folder. ".../MyProject/src
Now it appears in your project, and you can set breakpoints.
again ttach debugger
chose the process to debug.
debugger should stop if programm reaches next breakpoint.
Going to [window] -> [Debugging] -> Will your window make compfortable.