Posting a couple of lines from a c program is not enough to do any good.
The only debugging tool that I ever use is to insert a printf statement at strategic points in my program to see what's happening. It's low tech, I know. But it actually works very well.
Further to what Perderabo said, I use a form of printf to debug my programs.
Rather than displaying messages to screen, I would write those same messages to a log file.
This could obviously mean a very large file, which will mean a performance degredation, so the logging (or tracing) is conditional on a configuration setting being activiated e.g. an environment variable or in an configuration (or ini) file or a flag on a database table.
A trace level could also be defined e.g. 9 for most detailed to 1 for the least detail.
Although creating a mechanism to log to a file will require more programming effort, it will be invaluable to you if you have developed your program and delivered it to a 'live' system where your development tools won't be available. You may not be able to predict when your fault is going to happen either, especially with background or daemon processes.
After you have put in the effort to create your new logging functions, you may want to encapsulate them into a library for use in future projects. To this end I believe many Unix systems will provide standard functions to allow you to write messages to the system log if you prefer.
Whether you are logging to a file or the screen or even using a debugger I would recommend you track the following features of your program:
When a function is called
When a function exits.
The input values, or paramters to functions
The return values, or parameters of functions
When a variable is first assigned.
6 When a variable changes
(Be sure to display all strings within quotes so you can see any whitespace in the string)
This should allow you to tackle most faults in your program.
It's probably a better idea to use fprintf(stderr, ... ) so that any errors are IMMEDIATELY reported. Otherwise, your program may die before the stdout buffer makes it to the screen. I've had this happen MANY times where the last debugging line on the screen did NOT indicate where the program REALLY died. Either use stderr or use fflush() after writing to a log file.