How to properly debug a binary generated by `go test -c` using GDB?

Question

The go test command has support for the -c flag, described as follows:

-c  Compile the test binary to pkg.test but do not run it.
    (Where pkg is the last element of the package's import path.)

As far as I understand, generating a binary like this is the way to run it interactively using GDB. However, since the test binary is created by combining the source and test files temporarily in some /tmp/ directory, this is what happens when I run list in gdb:

Loading Go Runtime support.
(gdb) list
42      github.com/<username>/<project>/_test/_testmain.go: No such file or directory.

This means I cannot happily inspect the Go source code in GDB like I'm used to. I know it is possible to force the temporary directory to stay by passing the -work flag to the go test command, but then it is still a huge hassle since the binary is not created in that directory and such. I was wondering if anyone found a clean solution to this problem.

Eddy R. · Accepted Answer · 2015-08-29 03:44:31Z

4

Go 1.5 has been released, and there is still no officially sanctioned Go debugger. I haven't had much success using GDB for effectively debugging Go programs or test binaries. However, I have had success using Delve, a non-official debugger that is still undergoing development: https://github.com/derekparker/delve

To run your test code in the debugger, simply install delve:

go get -u github.com/derekparker/delve/cmd/dlv

... and then start the tests in the debugger from within your workspace:

dlv test

From the debugger prompt, you can single-step, set breakpoints, etc.

Give it a whirl!

answered Aug 29, 2015 at 3:44

Eddy R.

1,1297 silver badges12 bronze badges

Sign up to request clarification or add additional context in comments.

Comments

Linear · Accepted Answer · 2013-12-18 05:24:10Z

Unfortunately, this appears to be a known issue that's not going to be fixed. See this discussion:

https://groups.google.com/forum/#!topic/golang-nuts/nIA09gp3eNU

I've seen two solutions to this problem.

1) create a .gdbinit file with a set substitute-path command to redirect gdb to the actual location of the source. This file could be generated by the go tool but you'd risk overwriting someone's custom .gdbinit file and would tie the go tool to gdb which seems like a bad idea.

2) Replace the source file paths in the executable (which are pointing to /tmp/...) with the location they reside on disk. This is straightforward if the real path is shorter then the /tmp/... path. This would likely require additional support from the compiler / linker to make this solution more generic.

It spawned this issue on the Go Google Code issue tracker, to which the decision ended up being:

https://code.google.com/p/go/issues/detail?id=2881

This is annoying, but it is the least of many annoying possibilities. As a rule, the go tool should not be scribbling in the source directories, which might not even be writable, and it shouldn't be leaving files elsewhere after it exits. There is next to nothing interesting in _testmain.go. People testing with gdb can break on testing.Main instead.

Russ Status: Unfortunate

So, in short, it sucks, and while you can work around it and GDB a test executable, the development team is unlikely to make it as easy as it could be for you.

Mat Schaffer · Accepted Answer · 2015-04-16 06:59:41Z

1

I'm still new to the golang game but for what it's worth basic debugging seems to work.

The list command you're trying to work can be used so long as you're already at a breakpoint somewhere in your code. For example:

(gdb) b aws.go:54
Breakpoint 1 at 0x61841: file /Users/mat/gocode/src/github.com/stellar/deliverator/aws/aws.go, line 54.
(gdb) r
Starting program: /Users/mat/gocode/src/github.com/stellar/deliverator/aws/aws.test
[snip: some arnings about BinaryCache]

Breakpoint 1, github.com/stellar/deliverator/aws.imageIsNewer (latest=0xc2081fe2d0, ami=0xc2081fe3c0, ~r2=false)
    at /Users/mat/gocode/src/github.com/stellar/deliverator/aws/aws.go:54
54      layout := "2006-01-02T15:04:05.000Z"
(gdb) list
49  func imageIsNewer(latest *ec2.Image, ami *ec2.Image) bool {
50      if latest == nil {
51          return true
52      }
53
54      layout := "2006-01-02T15:04:05.000Z"
55
56      amiCreationTime, amiErr := time.Parse(layout, *ami.CreationDate)
57      if amiErr != nil {
58          panic(amiErr)

This is just after running the following in the aws subdir of my project:

go test -c
gdb aws.test

As an additional caveat, it does seem very selective about where breakpoints can be placed. Seems like it has to be an expression but that conclusion is only via experimentation.

answered Apr 16, 2015 at 6:59

Mat Schaffer

1,7021 gold badge15 silver badges26 bronze badges

1 Comment

Hi-Angel Over a year ago

⁺¹, I too see the source code in the gdb output. I'm not sure why didn't it work for the author, might be they forgot to mention something… Tested both with a minimal example project as well as with tests for a Packer plugin from Github.

0xcaff · Accepted Answer · 2016-12-25 04:16:50Z

If you're willing to use tools besides GDB, check out godebug. To use it, first install with:

go get github.com/mailgun/godebug

Next, insert a breakpoint somewhere by adding the following statement to your code:

_ = "breakpoint"

Now run your tests with the godebug test command.

godebug test

It supports many of the parameters from the go test command.

  -test.bench string
        regular expression per path component to select benchmarks to run
  -test.benchmem
        print memory allocations for benchmarks
  -test.benchtime duration
        approximate run time for each benchmark (default 1s)
  -test.blockprofile string
        write a goroutine blocking profile to the named file after execution
  -test.blockprofilerate int
        if >= 0, calls runtime.SetBlockProfileRate() (default 1)
  -test.count n
        run tests and benchmarks n times (default 1)
  -test.coverprofile string
        write a coverage profile to the named file after execution
  -test.cpu string
        comma-separated list of number of CPUs to use for each test
  -test.cpuprofile string
        write a cpu profile to the named file during execution
  -test.memprofile string
        write a memory profile to the named file after execution
  -test.memprofilerate int
        if >=0, sets runtime.MemProfileRate
  -test.outputdir string
        directory in which to write profiles
  -test.parallel int
        maximum test parallelism (default 4)
  -test.run string
        regular expression to select tests and examples to run
  -test.short
        run smaller test suite to save time
  -test.timeout duration
        if positive, sets an aggregate time limit for all tests
  -test.trace string
        write an execution trace to the named file after execution
  -test.v
        verbose: print additional output

Collectives™ on Stack Overflow

How to properly debug a binary generated by `go test -c` using GDB?

4 Answers 4

Comments

Comments

1 Comment

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

4 Answers 4

Comments

Comments

1 Comment

Comments

Your Answer

Sign up or log in

Post as a guest

Related