Stack Trace
  Home
  Introduction
  Getting KGDB
  Documentation
  Using KGDB
  Credits
  Miscellaneous
  Troubleshooting
  FAQ
  Support
  About KGDB
  KGDB Pronew

 

Once GDB is in command mode, you can look at the stack trace using backtrace command. This command shows a list of function calls starting from the function where a system call entered the kernel. For each function, it prints the source code file name and line number where next function was called and for the innermost function, where execution stopped. It also prints argument values to these functions.

We can break the debugger by pressing Ctrl + C, and see a stack trace as follows:

(gdb) backtrace
#0  breakpoint () at gdbstub.c:1160
#1  0xc0188b6c in gdb_interrupt (irq=3, dev_id=0x0, regs=0xc02c9f9c)
    at gdbserial.c:143
#2  0xc0108809 in handle_IRQ_event (irq=3, regs=0xc02c9f9c, action=0xc12fd200)
    at irq.c:451
#3  0xc0108a0d in do_IRQ (regs={ebx = -1072672288, ecx = 0, edx = -1070825472,
      esi = -1070825472, edi = -1072672288, ebp = -1070817328, eax = 0,
      xds = -1072693224, xes = -1072693224, orig_eax = -253,
      eip = -1072672241, xcs = 16, eflags = 582, esp = -1070817308,
      xss = -1072672126}) at irq.c:621
#4  0xc0106e04 in ret_from_intr () at af_packet.c:1878
#5  0xc0105282 in cpu_idle () at process.c:135
#6  0xc02ca91f in start_kernel () at init/main.c:599
#7  0xc01001cf in L6 () at af_packet.c:1878
Cannot access memory at address 0x8e000

Unless number of stack frames to be printed is specified as an argument to the backtrace command, gdb stops printing backtrace only when the stack trace goes out of accessible address space. The function call hierarchy as shown above is ret_from_intr,do_IRQ,handle_IRQ_event,gdb_interrupt.

Let's place a breakpoint in ext2_readlink and access a symbolic link so that the breakpoint is hit.

(gdb) br ext2_readlink
Breakpoint 2 at 0xc0158a05: file symlink.c, line 25.
(gdb) c
Continuing.

On running command ls -l /boot/vmlinuz on the test machine,

Breakpoint 2, ext2_readlink (dentry=0xc763c6c0, buffer=0xbfffed84 "\214\005",
    buflen=4096) at symlink.c:25
25              char *s = (char *)dentry->d_inode->u.ext2_i.i_data;
(gdb) bt
#0  ext2_readlink (dentry=0xc763c6c0, buffer=0xbfffed84 "\214\005",
    buflen=4096) at symlink.c:25
#1  0xc013b027 in sys_readlink (path=0xbfffff77 "/boot/vmlinuz",
    buf=0xbfffed84 "\214\005", bufsiz=4096) at stat.c:262
#2  0xc0106d83 in system_call () at af_packet.c:1878
#3  0x804aec8 in ?? () at af_packet.c:1878
#4  0x8049697 in ?? () at af_packet.c:1878
#5  0x400349cb in ?? () at af_packet.c:1878

GDB has printed some invalid stackframes in above backtrace. This is because gdb doesn't know where to stop a backtrace. We can ignore the stackframes 3 to 5 as they are invalid. The system call readlink entered the kernel at system_call function. The function is shown in af_packet.c which is incorrect. gdb is not able to figure out the correct code line, because it's a function in an assembly language file. GDB can handle inline assembly in c correctly. Further hierarchy is sys_readlink and ext2_readlink.

After this we remove the breakpoint with delete command and continue.

(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) c
Continuing.