We have a binary that generates coredump. So I ran the gdb command to analyze the issue. Pleae note the binary and code are in two different locations and we cannot build the whole binary using debugging symbols. Hence how and what details can I find from below backtarce:
gdb binary corefile
(gdb) where
#0 0x101fa37a in f1()
#1 0x10203812 in operator f2< ()
#2 0x085f6244 in f3 ()
#3 0x085f1574 in f4()
#4 0x0805b27b in sigsegv_handler ()
#5 <signal handler called>
#6 0x1018d945 in f5()
#7 0x1018e021 in f6()
..................................
#29 0x08055c5c in main ()
(gdb)
Please provide me gdb commands that I can issue to find what�s data inside each stack frame , what�s the issue probably is, where it is failing, other debugging methods if any?
Please state what Operating System and version you have and the Programming Language of the failed program.
Does the program ever work, or does it work normally and fail randomly?
Do you have the program source code?
What are the ulimit settings for the environment hosting the program?
What is the output from the unix "file" command on the core file (this should say why the program failed).
One tutorial (of many available with Google). gdb Tutorial
#1 looks interesting to me -- what calls could a reasonable < operator make that would cause a segfault? I would look at that function and see if there's anything obviously wrong.
FYI : if the binary is not compiled with a debug option,
the source with GDB will not help you at all, all you will see is hxa/binay codes for instructions, pointers (adresses) and data --
so unless you can read or have the time to translate machinecode (wich is possible) gdb will not help you .