You just need a binary (with debugging symbols included) that is identical to the one that generated the core dump file. Then you can run gdb path/to/the/binary path/to/the/core/dump/file to debug it.
When it starts up, you can use bt (for backtrace) to get a stack trace from the time of the crash. In the backtrace, each function invocation is given a number. You can use frame number (replacing number with the corresponding number in the stack trace) to select a particular stack frame.
You can then use list to see code around that function, and info locals to see the local variables. You can also use print name_of_variable (replacing "name_of_variable" with a variable name) to see its value.
Typing help within GDB will give you a prompt that will let you see additional commands.
Some generic help:
gdb start GDB, with no debugging les
gdb program begin debugging program
gdb program core debug coredump core produced by program
gdb --help describe command line options
First of all, find the directory where the corefile is generated.
Then use ls -ltr command in the directory to find the latest generated corefile.
To load the corefile use
gdb binary path of corefile
This will load the corefile.
Then you can get the information using the bt command.
For a detailed backtrace use bt full.
To print the variables, use print variable-name or p variable-name
To get any help on GDB, use the help option or use apropos search-topic
Use frame frame-number to go to the desired frame number.
Use up n and down n commands to select frame n frames up and select frame n frames down respectively.
To stop GDB, use quit or q.
Source: Stackoverflow.com