What Do You Use to Debug Linux / UNIX C/C++ Programs?

last updated in Categories Ask nixCraft, GNU/Open source, Linux, programming, UNIX

The purpose of a debugger is to allow you to see what is going on inside another program while it executes. It is useful to find out what another program was doing at the moment it crashed. I know most people will recommend GNU gdb, Nemiver, Valgrind or IDE such as Eclipse. I use gdb when it is really required; otherwise I debug the old fashioned way using printf() or cout statements.

I’m often too lazy for this, but gdb is used when really needed. I found Eclipse as a good alternative to debug programs. In the old days Borland C (Turbo C) was good enough for most of us. It was pretty slick and easy to use. However, UNIX / Linux is altogether different story with vi and gcc. What do you use to debug your C/C++/Java programs under UNIX like operating systems?



Posted by: Vivek Gite

The author is the creator of nixCraft and a seasoned sysadmin, DevOps engineer, and a trainer for the Linux operating system/Unix shell scripting. Get the latest tutorials on SysAdmin, Linux/Unix and open source topics via RSS/XML feed or weekly email newsletter.

26 comment

  1. Oh… I thought I was the only one on the planet that still preferred to use printf() and manual breakpoints and checkpoints and such.

    However, I’m probably one of the few old farts that would still rather use K&R C.

  2. I used to use plain old “print”, but I know that’s not the right way. I recently started learning python and have determined to myself that I will learn to develop with it in Eclipse with the Eclipse debugger. I’ve been doing this for too long to still be using print!

  3. What is wrong with using print?

    My personal observation is that people using a debugger tend to fix just *something*, but most often the underlying cause is neither found nor corrected.

    As an example, you expect an object to be passed to your method. The method is called several hundret times, and within one single call NULL is passed. It is hard to debug such things with a debugger (because it doesn’t happen always).

    For me print debugging leads to using loggers in hot spots. When I find adding myself a print a second time, I place an logger statement instead.

    When I make assumptions, (e.g NULL here, see example above) I add assert statements.
    Ofcourse loggers and asserts can also be used when you rely on an debugger instead, but many people often only do one thing.

    Last but not least, adding prints helps me to better understand control/dataflow logic. I don’t like hitting F5 (or whatever the hotkey is) over and over again, until I find the statement where my programm is doing something wrong.

    PS: I use a debugger when I have to programm non-function code, eg. OOP and need to know about several local or global states at a specific point in time.

  4. Me again:

    When I want to add a print, I really have to think about where to place it. I cannot fall into an automatism and just use my debugger. I have to use my brain and IMHO that is all programming is about.

    I feel sick whenever I see people starting their debugger in order to understand what a piece of code is doing. A debugger is a tool, nothing to abuse.

  5. Me again: (sorry for potential double post, just wondering where the second post went to)

    When I want to add a print, I really have to think about where to place it. I cannot fall into an automatism and just use my debugger. I have to use my brain and IMHO that is all programming is about.

    I feel sick whenever I see people starting their debugger in order to understand what a piece of code is doing. A debugger is a tool, nothing to abuse.

  6. I usually combine traces with gdb. I commonly use a function which, when a DEBUG_FLAG is enabled prints the message, file and function name and line number. When I need to know the exact state of my program at some point, I use gdb (probably with conditional breakpoints). Then, when everything is ok, I turn out the flag and I get the nice robust program I was looking for (-:

  7. defentialy a debuger.
    Using printf() and assertions is great if you have those already covering you complete code. Unfortunatly, while this is a good practice, it is not the case in many cases.
    If the application is more than trivial it is dificult to effectively add printf() etc’ when you need to debug.

  8. I think there’s not any “one fits all” debugger, almost every time i use gdb, but when i have to deb ug complex data structures, i use ddd; for memory leaks and lost pointers i found nothing better than memwatch (http://sourceforge.net/projects/memwatch/).

    Never marry with only one tool… there’s always a feature inside one that is missing on another one, IMHO.


  9. I am the product manager for a debugger vendor. Yes, that’s right there is a company out there that actually has managed to stay in business (for about 10 years) specializing in debugging on Linux/UNUX.

    I’d encourage you to check out TotalView. It is a professionally developed debugger for apps running on C/C++ and Fortran on Linux and other UNIX OSs. It is compiler agnostic and plays nicely with GDB, Intel, PGI, and others.

    It has some really nice C++ features like automatic translation of STL variables, and has world-class support for threads and processes (up to 16k of them, in recent tests on the linux powered BlueGene platform).

    It is _not_ based on GDB (unlike most of the other GUI debugging solutions you will find in UNIX-land). GDB is nice, but having a separate code-base lets us be bug orthogonal.. as a previous poster said “never marry yourself to a single tool”. Which is sensible advice.

    The best feature is something that we recently added via an add-on called ReplayEngine. WIth TV and RE you can step freely forwards and backwards through your code. So you can run to a crash and then work backwards from there to the error in your program.

    I understand that you might be skeptical. So I encourage you to check out the videos and download a free copy to try out (we offer a free 15 day evaluation period).

    Feel free to contact me at (fn).(ln)@totalviewtech(dot)com with feedback (good, bad, or ugly) or questions.

    Chris Gotbrath

  10. Ok, this is embarrasing. There are two typos in my post above. Somehow I managed to type UNIX as UNUX. More confusingly I somehow omitted a ‘t’ in my own last name. So if you want to send me an email please use chris(dot)gottbrath(at)totalviewtech(dot)com with two ‘t’s.

    Chris Gottbrath

  11. hi i am relatively new to the world of C programming and m having a tough time debugging my programs. i mostly have to del with matirx related problem and one wrong dimension and thw whole program chrashes. i ma working on UNIX. can anybody give me an idea about the debugging tools available

  12. Rima,

    just take the core and analyse it with gdb. It will give you the information where mess up has happened. In matrix kinda problems, usually its dimension issues. Not sure you may be needing some validation in your code.

  13. How do i actually get to know the exact syntax error in the c program when the compiler gives error as ‘Segmentation fault’?

  14. I use WiCon wireless console on my iPhone to see debug messages out of main screen and to control my programs runing by sound.

    Have a question? Post it on our forum!