Go Program Debugging Summary

This is a creation in Article, where the information may have evolved or changed.

The first thing to note is that after the golang1.3 version, there is a big problem with supporting GDB debugging. The reason for this problem is that Golang's runtime is not fully supported by GDB.

The latest version of full support for GDB debugging is Golang 1.2.2, but there are also individual problems.

Why the above problems, Golang official website gives the explanation is:

GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo. As a consequence, although GDB can be useful in some situations, it is not a reliable debugger for Go programs, particularly heavily concurrent ones. Moreover, it is not a priority for the Go project to address these issues, which are difficult. In short, the instructions below should be taken only as a guide to how to use GDB when it works, not as a guarantee of success.

Translation:

GDB不能很好的理解GO程序。堆栈管理、线程和runtime包含了非常不一样的执行模式，这不是GDB期望的，他们会扰乱调试器，即使go程序是使用gccgo编译的。结果就是，虽然GDB在某些场合下是有用的，但是对go程序来说并不是一个可靠的调试器。尤其是在大量并发的时候。而且，这不是Golang项目优先考虑的事情，这很困难。总而言之，下面的操作手册，只是当GDB正常工作的时候，引导你如何使用GDB，不能保证总是成功。

And from the Google Group discussion group and StackOverflow, you can see that multiple versions of Golang have such problems with GDB support. But since the Official handbook says so, we can only use GDB on the right occasions.

By default, the compiled binaries already contain DWARFv3 debug information, as long as the GDB7.1 or later versions are available for debugging. Under OSX, if you can't execute debug commands, try to execute gdb with sudo.

When compiling the Go program, you need to close inline optimization: * *-gcflags "-n-l" * *. You can go get/build/test specify this parameter at the time.

There are two ways to lower breakpoints:

• After the GDB command is run, use the break File:lineno
• Use runtime. Breakpoint ()

Demo Environment: Ubuntu 14.04 LTS Amd64/golang 1.2.2/gdb 7.7

package mainimport (    "fmt"    "runtime")func test(s string, x int) (r string) {    r = fmt.Sprintf("test: %s %d", s, x)    runtime.Breakpoint()    return r}func main() {    s := "haha"    i := 1234    println(test(s, i))}

Start GDB:

➜  ~  gdb ./testGNU gdb (Ubuntu 7.7-0ubuntu3) 7.7Copyright (C) 2014 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later 
  
   
    
   This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.  Type "show copying"and "show warranty" for details.This GDB was configured as "x86_64-linux-gnu".Type "show configuration" for configuration details.For bug reporting instructions, please see:
   
    .Find the GDB manual and other documentation resources online at:
   
    .For help, type "help".Type "apropos word" to search for commands related to "word"...Reading symbols from ./test...done.**Loading Go Runtime support.**(gdb)
  
   

View the source code in the form of a module name:

(gdb) l main.main9       r = fmt.Sprintf("test: %s %d", s, x)10      runtime.Breakpoint()11      return r12  }1314  func main() {15      s := "haha"16      i := 123417      println(test(s, i))

To view the source code as a filename plus line number:

(gdb) l /home/roy/test.go:11   package main23   import (4       "fmt"5       "runtime"6   )78   func test(s string, x int) (r string) {9       r = fmt.Sprintf("test: %s %d", s, x)10      runtime.Breakpoint()

To set breakpoints:

(gdb) b main.mainBreakpoint 2 at 0x400d80: file /home/roy/test.go, line 14.(gdb) b test.go:18Breakpoint 3 at 0x400e0e: file /home/roy/test.go, line 18.

Start the process, triggering the breakpoint: (n stepping, c executing to the next breakpoint)

(gdb) runStarting program: /home/roy/testBreakpoint 2, main.main () at /home/roy/test.go:1414  func main() {

View Goroutines:

(gdb) info goroutines* 1  running runtime.gosched* 2  syscall runtime.notetsleepg

To view the call stack for the specified goroutine:

(gdb) goroutine 1 btPython Exception 
  
   
    
    Cannot access memory at address 0x8:Error occurred in Python command: Cannot access memory at address 0x8
  
   

GDB reports no access to memory when we want to view the Goroutine call stack. Cannot access memory at address 0x8, which means that 0x8 the memory of the location cannot be accessed, so next, GDB receives a SIGSEGV signal stating that a segment error has been triggered:

(gdb) nProgram received signal SIGSEGV, Segmentation fault.0x000000000041529b in runtime.gosched () at /home/roy/go/src/pkg/runtime/proc.c:13681368        runtime·mcall(runtime·gosched0);

At this point, we need to restart GDB's debugging, otherwise the execution of any command will report a segment error.

Print stack frame information:

(gdb) info frameStack level 0, frame at 0x7ffff7e2ef48: rip = 0x400d80 in main.main (/home/roy/test.go:14); saved rip = 0x412e1f source language go. Arglist at 0x7ffff7e2ef38, args: Locals at 0x7ffff7e2ef38, Previous frame's sp is 0x7ffff7e2ef48 Saved registers: rip at 0x7ffff7e2ef40

To view local variables:

(gdb) info localsi = 1234s = "haha"

To print a variable in pretty-print way:

(gdb) p s$1 = "haha"

Gets the length of the object, which is the CAP:

(gdb) p $len(s)$3 = 4

To view object types:

(gdb) whatis itype = int(gdb) whatis stype = struct string

Enter N to step into the test function to see the arguments passed to the function:

(gdb) nmain.test (s="haha", x=1234, r="test: haha 1234") at /home/roy/test.go:1111      return r(gdb) info argss = "haha"x = 1234r = "test: haha 1234"

Enter Q, or ctrl-d exit:

(gdb) qA debugging session is active.    Inferior 1 [process 6079] will be killed.Quit anyway? (y or n) y