I think most C compilers on most flavors of *nix support -g to include debugging symbols within the object files, so if you do:

cc -g -c file1.c
cc -g -c file2.c
cc -g file1.o file2.o -o program
./program

Then when you run program if it crashes it should produce a more easily debugged core file. The first two lines just compile source files (producing .o files), the third line tells the compiler to call the linker to link the source files into an executable (passing -g here may not actually do anything if the linker does not have to do anything special to produce an executable with debugging symbols, but it should not hurt anything), and the last line runs the program. You should make sure that you do not tell the compiler to do optimizations when you are trying to debug (unless you find that it does not have errors unless optimizations are turned on) because optimizations typically make the more difficult to follow.

Since I don't know what platform you are on or what tools you have available (or really even what C compiler you are using) so it is difficult to give more specific advice. You should read the man page (manual) for your complier. From the command line type:

man cc

And that should bring up a manual page that tells you lots of things about the compiler on your system. This may tell you how to tell the compiler to produce more warning messages, which could help you find your errors before even running your programs. (note that some warnings may only be produced if you compile with certain optimizations turned on, so even though you probably won't want to debug the optimized program you may want to compile it with optimizations and extra warnings turned on just to see if they tell you anything).

Your Unix system probably has some type of debugger installed. Most Linux machines set up for C development have gdb installed. gdb can be used to run your program in debug mode or to analyze a core file. If you have gdb you can:

gdb ./program

it will start up ready to run your program. If you do:

gdb ./program ./core

it will behave similarly except that it will be as though you were debugging and your program just crashed. From this state the quickest and most helpful thing you can do is to

(gdb) bt

Here (gdb) is the prompt and bt is a command that says to produce a back-trace. That means a call stack, which shows what function the program was in when the failure happened, and what function called that function, and what function called that function, and on and on up to the first function. This can be confusing because it will often show library functions as the most recent called, but this usually means that you have passed in some bad data somewhere along the way that is causing the problem.

gdb is a large and complex program so if it is on your system you should take the time to read up on it.

If it is not on your system then you should find out what similar tools are. Some of the graphical debuggers (either within an IDE or not) act as front ends to command line debuggers and some even support several different command line debuggers, so if you are able to use one of the graphical debuggers you may not actually have to worry about what actual back end command line debugger is being used.