mailgun/godebug

DEPRECATED! https://github.com/derekparker/delve

godebug's Issues

godebug test runs with the wrong wd if invoked on a named package

go test runs at the path of the package, so godebug test does the right thing only when executed as godebug test

malformed fp constant exponent

I was trying godebug out with one of my projects today and I got this error message:

/var/folders/t9/9tt1kghs13qb57tn266lwmzd957b86/T/godebug040698979/1p.go:11: malformed fp constant exponent
/var/folders/t9/9tt1kghs13qb57tn266lwmzd957b86/T/godebug040698979/1p.go:11: syntax error: unexpected literal 1p, expecting name or (
/var/folders/t9/9tt1kghs13qb57tn266lwmzd957b86/T/godebug040698979/1p.go:11: malformed fp constant exponent
/var/folders/t9/9tt1kghs13qb57tn266lwmzd957b86/T/godebug040698979/1p.go:18: malformed fp constant exponent
/var/folders/t9/9tt1kghs13qb57tn266lwmzd957b86/T/godebug040698979/1p.go:18: syntax error: unexpected name, expecting )
/var/folders/t9/9tt1kghs13qb57tn266lwmzd957b86/T/godebug040698979/1p.go:20: malformed fp constant exponent
/var/folders/t9/9tt1kghs13qb57tn266lwmzd957b86/T/godebug040698979/1p.go:20: syntax error: unexpected name, expecting semicolon or newline or }
/var/folders/t9/9tt1kghs13qb57tn266lwmzd957b86/T/godebug040698979/1p.go:66: malformed fp constant exponent

/var/folders/t9/9tt1kghs13qb57tn266lwmzd957b86/T/godebug040698979/1p.go:66: syntax error: unexpected literal 1p, expecting name or (

any ideas?

$ go version
go version go1.4.2 darwin/amd64

Build error with multiple var declaration inside anonymous func

godebug fails to build some code with multiple var declaration : https://github.com/hectorj/godebug/blob/multiple-var-declaration/testdata/single-file-tests/multiple-var-declaration-in.go

If you run the tests on that branch with -accept=true, it fails like this :

--- FAIL: TestGoldenFiles (4.39 seconds)
    endtoend_test.go:204: Golden file multiple-var-declaration-out.go failed to run under 'go run': exit status 2
        # command-line-arguments
        testdata/single-file-tests/multiple-var-declaration-out.go:21: undefined: y
        testdata/single-file-tests/multiple-var-declaration-out.go:21: undefined: err
        testdata/single-file-tests/multiple-var-declaration-out.go:25: undefined: y
        testdata/single-file-tests/multiple-var-declaration-out.go:27: undefined: err
        testdata/single-file-tests/multiple-var-declaration-out.go:29: undefined: err
        testdata/single-file-tests/multiple-var-declaration-out.go:31: undefined: y

But the "in" code is valid

nice to have: accept multiple commands in one line, or a "implicitly list after every command" mode

I find my self stepping through code with the following key press sequence

n <enter> l <enter>
n <enter> l <enter>
n <enter> l <enter>
n <enter> l <enter>

alot!

It would be a nice usability feature to be able issue two commands in a row on one line, e.g. "n l" at once to step to the next line and then view the listing of where I am at, so that subsequently I could just press enter to step and view where I am in one press of .

n l <enter>
<enter>
<enter>
<enter>

Alternatively it could be very nice just to have "listing on" mode, where there is an implicit l (list) command issued after every other command. This would be nice when mixing 'n' and 's' and 'f' ('f' is not yet available, I know :).

Support interaction with godep

A lot of go programs use https://github.com/tools/godep for dependency management, which also provides a "wrapper" command (godep go build, godep go test, etc) for manipulating GOPATH. Dunno if this is possible, but it would be very handy to be able to godebug projects that use godep.

Remove double build when Go 1.5 is released

godebug currently invokes go build twice as a workaround for how the go tool handles GOPATHs with multiple directories. In Go 1.5, this should be fixed.

godebug test can't test multiple packages

cannot use -c flag with multiple packages

godebug should be aware of identifiers in the package block

Currently it is only aware of identifiers in function body and block statement scopes

Return and quit commands

• Return from the current function
• Quit the program

Any plans for these?

cgo may through off godebug

at 606f703

under go1.4.1, under goq, on vagrant/linux/amd64, it looks like CGO functions may throw off godebug

vagrant@mailgun-dev:~/goq$ godebug -w .
/home/vagrant/goq/inspecterrno.go:14:17: undeclared name: _Cfunc_addr_of_errno
/home/vagrant/goq/inspecterrno.go:26:13: undeclared name: _Cfunc_errno_itself
Error loading packages: couldn't load packages due to errors: .

Usage of godebug:

godebug <flags> <args>

flags:
  -w=false: write result to (source) file instead of stdout

<args> is a list of arguments denoting a set of initial packages.
It may take one of two forms:

1. A list of *.go source files.

   All of the specified files are loaded, parsed and type-checked
...

http server support?

Hello,

I'm trying debug code like this:

package main

import (
    "fmt"
    "log"
    "net/http"
)

func main() {
    _ = "breakpoint"
    var count int
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hello, world") })
    go log.Fatal(http.ListenAndServe(":8080", nil))
    fmt.Println(count)
}

but it stop at line

go log.Fatal(http.ListenAndServe(":8080", nil))

any one help me?

change breakpoint syntax?

The current syntax for inserting a breakpoint in a source file is

godebug.SetTrace()

This was inspired by pdb's syntax, but I don't like that it also requires an import:

import "github.com/mailgun/godebug/lib"

This requires memorizing two incantations rather than just one. It's more complicated to explain in documentation. Also, if you happen to have an identifier named "godebug" already, this syntax produces an invalid Go program. Also, importing the godebug library requires you to have it present in your GOPATH. You can't just download and run the godebug binary.

I'm leaning toward changing the syntax to be a comment. It's only one line. It won't cause your program to be invalid. You don't have to have the godebug library in your GOPATH.

We would need to settle on what the comment should be. Two criteria are that it should be (1) easy to remember and (2) unlikely to conflict with other comments. Some possibilities:

// breakpoint
// godebug: break
// godebug: breakpoint
// godebug: set_trace

One minor downside is that it is possible to insert the comment in places where you can't actually break, like package-level variable declarations, so we would have to add some extra messaging for that case.

We could also allow invalid Go syntax to specify the breakpoint, but I don't think I want to do that.

Thoughts?

parseTestArguments won't work with long options without =

If for example I were to specify -instrument foo/bar it would fail to recognize foo/bar as the argument.

support stepping into the standard libarary

godebug's current procedure for running instrumented code for a package x is:

• make a temp directory
• make a subdirectory $TMP/src/x containing instrumented versions of the source files for x
• run the go command, setting GOPATH=$TMP:$GOPATH. The go command finds our instrumented packages in $TMP/src and finds any other un-instrumented packages in the normal GOPATH.

That process does not work for standard library packages, though, because $GOROOT has to be a single directory.

Here's my current plan for working around this:

• Implement the proposal from #8 of having a permanent godebug directory that contains instrumented versions of all the packages we have seen so far. Put standard library packages in the same place, or possibly in their own /goroot or /std directory.
• From the same proposal, generate a temporary directory for every invocation of godebug and fill it with symlinks to the packages we want to instrument. The only new thing is that for all standard library packages we don't want to instrument, we will need to add a symlink to the real package in $GOROOT.

surprising behavior with -instrument and godep

I am debugging a program that has a dependency on package foo, and I want to step into function calls in foo. So I run:

$ godebug run -instrument=foo myProg.go

godebug runs without complaint. Yet, to my surprise, I still can't step into foo. Why? Because I had forgotten that I was using godep. I would have been fine if I had instead run:

$ godebug run -instrument=my/package/name/Godeps/_workspace/src/foo

It would be nice if godebug caught this for me. At a minimum, it could have noticed that I didn't import package foo anywhere, and warned me that it was useless to pass that package in the instrument flag.

Alternatively, maybe we should get rid of the -instrument flag entirely. Having it sacrifices some usability for performance, but I don't understand the tradeoff very well. How much performance would we lose by instrumenting everything? Can we make that better? How often does the flag cause surprising behavior?

UX improvement: `godebug <run, test, build>`

Currently, godebug requires you to overwrite your files with the code-generated versions. It would be a big UX improvement to generate the files in a temporary directory and run them in a single step, like go test and go coverage.

godebug test fails for packages with external tests

If a package foo has EXTERNAL TEST (that is, tests with package declaration foo_test), writerFor will be invoked with a importPath like foo_test instead of foo, which will fail findUnderGopath.

Flag to automatically break at program/test start

I suppose this can always be done manually by putting _ = "breakpoint" as the first line in your main or Test* funcs, but it would be really handy to be able to go to any main package and just do godebug run or godebug test and be debugging immediately.

Perhaps an optional -debug.break flag or something could enable this: godebug run -debug.break and godebug test -debug.break

undefined: scope

The following program doesn't work:

package main
import (
    "os"
)
func main() {
    if o := os.Getenv("O"); o != "" {
        println(o)
    } else if s := os.Getenv("S"); s != "" {
        println(s)
    }
}

Allow to build/run packages, not only lists of go files

Preserve line numbers with compiler directives

It's possible to annotate lines so that they are treated as different line numbers in stack traces (panics, ...) and logs (test output, ...)

https://golang.org/cmd/gc/

Is it possible to dereference pointers?

I tried p *ptrVar but that didn't work, and I expected it would.

end-to-end tests are slow

The latest run on my MacBook Pro took 9.5 seconds. Speeding up the tests will make iterations easier, and will probably also optimize normal runs of godebug too.

gdb like 'fin' command to run until finished with function

godebug is working really nicely now(!)

stepping through code, one thing I miss is the 'fin' command from gdb. Small feature request would be to add it to godebug. 'fin' lets you continue running until the current function returns.

theory of operation

Hi Jeremy,
this is really interesting. It would be great if you could describe the theory of operation (say in the README).
Best,
Jason

Don't show loop header after break statement

After a loop reaches a break statement, godebug unnecessarily prints the loop statement again.

$ cat min.go
package main

func main() {
    _ = "breakpoint"
    for i := 1; i < 5; i++ {
        break
    }
}
$ godebug run min.go
-> _ = "breakpoint"
(godebug) n
-> for i := 1; i < 5; i++ {
(godebug) n
-> break
(godebug) n
-> for i := 1; i < 5; i++ {
(godebug) n
$

Though note this doesn't happen if no variables are declared in the loop statement:

$ cat min.go
package main

func main() {
    _ = "breakpoint"
    for {
        break
    }
}
$ godebug run min.go
-> _ = "breakpoint"
(godebug) n
-> for {
(godebug) n
-> break
(godebug) n
$

Open source it

Seems like a cool project for open source collaboration. Just add APACHE licence and blog aboit it :-)

Debug With Multiple GO Files ?

Hi, I'm developing rest api and my project folder looks like :

ProjectFolder

• main.go
• handlers.go (breakpoint in here)
• routes.go
• etc...

how can I debug my project ?
godebug run main.go didn't work.

declarations only used inside subsequently defined closures problematic: error "printf.go:485:6: argType declared but not used"

Tried running godebug on my light fork of Ross' c2go. It errored out on un-used declaration. The declaration is used, but only inside a closure defined later in that function.

prep:
go get github.com/glycerine/c2go

jaten@mbp13:~/go/src/github.com/glycerine/c2go$ godebug run *.go
printf.go:485:6: argType declared but not used
couldn't load packages due to errors: main
jaten@mbp13:~/go/src/github.com/glycerine/c2go$ 

minimal test case small.go:

package main

func takeClosure(f func(i interface{})) {
}

func main() {
    var touchedInClosure string
    takeClosure(func(i interface{}) {
        switch i.(type) {
        case string:
            touchedInClosure = "I have been written to!"
        }
    })
}

results on minimal test case small.go

jaten@mbp13:~/go/src/github.com/glycerine/c2go$ godebug run small.go
small.go:7:6: touchedInClosure declared but not used
couldn't load packages due to errors: main
jaten@mbp13:~/go/src/github.com/glycerine/c2go$ 

c2go is probably a nice small-medium sized program to try godebug on; I would suggest confirming that godebug works on it in full.

Print stack trace

It would be helpful to print the function stack in times I forget where I am in the current goroutine.

Run benchmarks

Inserting debugging calls at every line definitely slows the program down. But by how much? Some benchmarks would be nice.

Support build tags

For example, -tags might be unavoidable

instrumentation error "cannot use _ as value"

Hi guys,

Awesome piece of work BTW. Are you thinking about a code coverage extension at all :)

When instrumenting github.com/ugorji/go/codec I get some lines that look like:

• /var/folders/rh/l35fk0qd6gn4nc0czl94q37r0000gn/T/godebug838019398/src/github.com/ugorji/go/codec/fast-path.generated.go:4755: cannot use _ as value

followed by:

• too many errors

and the program gives up.

Is there some way around this without changing the third party code? Is there a way to skip one file in a package?

Thanks for any help.

Regards,
Kyle

crash at godebug/astutil.go:79

on the vagrant box on my mac, running go1.3.3 linux/amd64
I install github.com/glycerine/goq, then try running godebug on it. It crashes as follows:

vagrant@mailgun-dev:~/goq$ godebug -w .
package main
func main() {defer godebug.SLine(ctx, scope, "<Running deferred function>: defer os.Remove("hi.there")")}panic: 2:\
93: expected ')', found 'IDENT' hi

goroutine 16 [running]:
runtime.panic(0x6a4040, 0xc2134e3500)
    /home/vagrant/pkg/go1.3.3/go/src/pkg/runtime/panic.c:279 +0xf5
main.astPrintf(0xc213496c40, 0x3f, 0xc2134e3160, 0x2, 0x2, 0x0, 0x0, 0x0)
    /home/vagrant/go/src/github.com/mailgun/godebug/astutil.go:79 +0x40e
main.(*visitor).Visit(0xc2134e0700, 0x7ffa322e3ef0, 0xc20e43c8b0, 0x0, 0x0)
    /home/vagrant/go/src/github.com/mailgun/godebug/gen.go:622 +0x1a86
go/ast.Walk(0x7ffa322e3fb0, 0xc2134e0700, 0x7ffa322e3ef0, 0xc20e43c8b0)
    /home/vagrant/pkg/go1.3.3/go/src/pkg/go/ast/walk.go:52 +0x58
go/ast.walkStmtList(0x7ffa322e3fb0, 0xc2134e0700, 0xc20985c700, 0x9, 0x10)
    /home/vagrant/pkg/go1.3.3/go/src/pkg/go/ast/walk.go:32 +0xd1
go/ast.Walk(0x7ffa322e3fb0, 0xc2134e0700, 0x7ffa32407850, 0xc20e43e930)
    /home/vagrant/pkg/go1.3.3/go/src/pkg/go/ast/walk.go:224 +0x41e7
go/ast.Walk(0x7ffa322e3fb0, 0xc2134e05b0, 0x7ffa322e42b0, 0xc20e43cad0)
    /home/vagrant/pkg/go1.3.3/go/src/pkg/go/ast/walk.go:98 +0x3587
go/ast.walkExprList(0x7ffa322e3fb0, 0xc2134e0310, 0xc20e2b8280, 0x3, 0x4)
    /home/vagrant/pkg/go1.3.3/go/src/pkg/go/ast/walk.go:26 +0xd1
...

UX improvement: remove ambiguity between commands and variable names

A story

If I want to print the variable a, I type "a". If I want to print the variable b I type "b". If I want to print the variable c I type "c"...

whoops, I just ran the continue command instead of printing my variable.

The problem

godebug lets you print variables by typing their name. But if you build that habit and then want to print a variable with the same name as a godebug command, you will probably run a command you do not intend to, by accident. godebug should either detect the ambiguity or, preferably, not take inputs that can be ambiguous in this way.

The easiest thing is probably to only print variables when the user types the "(p)rint" command.

Questions

What command syntax should we use when godebug is expanded to evaluate full expressions?
How do other debuggers handle this? In particular, what does pdb do?

"no buildable Go source files"

Given this directory structure:

a $ tree
.
├── a.go
└── b
    ├── b.go
    └── c
        └── c.go

2 directories, 3 files

a $ cat a.go
package main

import (
    "a/b"
    "a/b/c"
)

func main() {
    b.B()
    c.C()
}

a $ cat b/b.go
package b

func B() {
    println("B")
}

 a $ cat b/c/c.go
package c

func C() {
    _ = "breakpoint"
    println("C")
}

Running godebug without -instrument gives a helpful warning:

 a $ godebug run a.go
godebug run: Ignoring breakpoint at a/b/c/c.go:4 because package "c" has not been flagged for instrumentation. See 'godebug help run'.

B
C

But the -instrument flag does not work as expected:

$ godebug run -instrument a/b/c a.go
/var/folders/4l/d1lsmz5d4972rfkg1gvv8hmc0000gn/T/godebug895759339/a.go:4:2: no buildable Go source files in /var/folders/4l/d1lsmz5d4972rfkg1gvv8hmc0000gn/T/godebug895759339/src/a/b

About the example

Hi,

I typed following code in the example dir:

 godebug -w .

And got:

godebug is a tool for debugging Go programs.

Usage:

        godebug command [arguments]

The commands are:

    run       compile, run, and debug a Go program
    test      compile, run, and debug Go package tests
    output    generate debug source code, but do not build or run it

Use "godebug help [command]" for more information about a command.

So the usage of example/README.md is incorrect.

Some packages are not vendored

Any reason some packages are vendored and some others are not?

Like

    "bitbucket.org/JeremySchlatter/go-atexit"
    "github.com/kisielk/gotool"

gb compatibility

Is it possible to make this compatible with gb?

Useful for metrics

This is very simple, but I like it.
I think metrics can also be done this way. On large deployment foot print projects fixing a bug can require putting in a metric to watch it in production.

I also like the idea of putting in alarms and weightings in the code.

The devops team can't know what to measure at the application level. They only know high level generic things they need to measure.

What do people think of develops being able to describe these aspects in the code at design time ??

Failing during third party lib refence

i have third party c++ library reference in my project. when i execute

$godebug run main.go
it gives error ''library.dll' is missing

undefined: godebug.EnteringNewScope

e57fb7e

Hi @jeremyschlatter, having some trouble trying the latest godebug. go1.4.2. centos6.6/amd64. Please advise. Thanks!

Jason

$ go run me.go
usage: 
exit status 1
$ 

# yes. minified example runs as expected. now try under godebug:

$ godebug run me.go
# command-line-arguments
/tmp/godebug572895385/me.go:9: undefined: godebug.EnteringNewScope
$ cat me.go
package main

import (
    "fmt"
    "os"
)

func usage() {
    fmt.Fprintf(os.Stderr, "usage: \n")
    os.Exit(1)
}

func main() {
    if len(os.Args) < 4 {
        usage()
    }
    a := os.Args[1]
    b := os.Args[2]
    c := os.Args[3]

    fmt.Fprintf(os.Stderr, "me! %v %v %v\n", a, b, c)

}
$

again with -godebugwork and the start of the output shown

$ godebug run -godebugwork me.go
/tmp/godebug438483676
# command-line-arguments
/tmp/godebug438483676/me.go:9: undefined: godebug.EnteringNewScope

$ cat /tmp/godebug438483676/me.go
package main

import (
    "fmt"
    "github.com/mailgun/godebug/lib"
    "os"
)

var me_go_scope = godebug.EnteringNewScope(me_go_contents)

func usage() {
    ctx, ok := godebug.EnterFunc(usage)
    if !ok {
        return
    }
    defer godebug.ExitFunc(ctx)
    godebug.Line(ctx, me_go_scope, 9)
    fmt.Fprintf(os.Stderr, "usage: \n")
    godebug.Line(ctx, me_go_scope, 10)
    os.Exit(1)
}

func main() {
    ctx, ok := godebug.EnterFunc(main)
    if !ok {
        return
...

The list command should display the file name and line number

godebug run command not works

the source of hello.go is

package main

import (
    "fmt"
)

func main() {
    x := "Hello"
    _ = "breakpoint"
    y := "World"
    _ = "breakpoint"
    z := "Go"
    _ = "breakpoint"
    w := x + " " + y + " " + z
    _ = "breakpoint"
    fmt.Println(x, y, z)
    fmt.Println(w)
}

godebug run command shows error message like:

P:\go\src>godebug run hello.go
# command-line-arguments
C:\go\pkg\tool\windows_386\8l.exe: dwarf: unresolved references after first dwar
f info pass

however, the following command works well. (tested in git shell on win)

Home@HOME-PC /p/go/src
$ godebug output hello.go > hello.debug.go

Home@HOME-PC /p/go/src
$ go run hello.debug.go
-> _ = "breakpoint"
(godebug) l
...

... i mistype the command?

feature: repeat last command on enter

Really missing that one and looks easy to add.

godebug build not using generated package files

Greetings, thank you for creating such an awesome tool for go developers. I have tried to use godebug to debug my project with many packages, I use following command to build:

godebug.exe build -instrument=github.com/..../cms/data

And then run the built binary but no breakpoint is activated.

Then I use -godebugwork to get generated go files, copy all the generated package files to origin directory, and use normal go build/run, I can then successfully enter the breakpoint and print vars etc...

I wonder why godebug build didn't use its generated files to build the executable, whether it's a bug or what did I do wong?

Thank you!

feature: evaluate Go expressions

top priority: selector expressions and index expressions

Add readline support

Usage with ide integrations ?

Just wondering if there are any currently.
Or even an api that I could use to do an integration.

How run it right here in your browser with gopherjs？