Delve is a debugger for the Go programming language.
License: MIT License
The GitHub issue tracker is for bugs only. Please use the developer mailing list for any feature proposals and discussions.
Delve is a debugger for the Go programming language. The goal of the project is to provide a simple, full featured debugging tool for Go. Delve should be easy to invoke and easy to use. Chances are if you're using a debugger, things aren't going your way. With that in mind, Delve should stay out of your way as much as possible.
tried to "go get" delve just now, but its build is broken:
/statusIcon.svg)
jaten@c:~/go/src/github.com/derekparker/delve:master$ go get github.com/derekparker/delve/cmd/dlv
# golang.org/x/sys/unix
/home/jaten/go/src/golang.org/x/sys/unix/asm.s:6 6a: No such file or directory: textflag.h
jaten@c:~/go/src/github.com/derekparker/delve:master$ sudo locate textflag.h
/var/mailgun/cutlass/jaten/pkg/go1.2.1/go/src/cmd/ld/textflag.h
/var/mailgun/cutlass/jaten/pkg/go1.2.1with_http_improved/go/src/cmd/ld/textflag.h
/var/mailgun/cutlass/jaten/pkg/go1.3.1/go/src/cmd/ld/textflag.h
/var/mailgun/cutlass/jaten/pkg/go1.3.3/go/src/cmd/ld/textflag.h
/var/mailgun/cutlass/jaten/pkg/go1.4/go/pkg/linux_amd64/textflag.h
/var/mailgun/cutlass/jaten/pkg/go1.4/go/src/cmd/ld/textflag.h
jaten@c:~/go/src/github.com/derekparker/delve:master$
3.11.0-26-generic #45~precise1-Ubuntu SMP
linux/amd64
Since the program terminates with "die" (or Term.die), defer statements like "defer os.Remove(debugname)" are lost.
One possible solution is to add a Term.defer method that stores the functions passed in input in a list and executes them when Term.die() is called.
$ go version
go version go1.3.3 linux/amd64
$ ./dlv -run
Type 'help' for list of commands.
dlv> goroutines
Command failed: could not find symbol value for goid
I'm happy to try figure this out.
Steps to reproduce - I'm using GCE to run in on centos 7 image.
Output:
--- FAIL: TestStep (0.17s)
proctl_test.go:52: Break() : could not set hardware breakpoint: invalid argument
FAIL
$ cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core)
$ rpm -q glibc
glibc-2.17-55.el7_0.3.x86_64
$ uname -a
Linux delve01 3.10.0-123.13.1.el7.x86_64 #1 SMP Tue Dec 9 23:06:09 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ go version
go version go1.4.1 linux/amd64
# at commit 46e5cfd39963a489f6e4fc43ad3a9f78b9f5321b
strace -o trace.out -s 2048 ./proctl.test -test.run=TestStep
grep ptrace trace.out
ptrace(PTRACE_SETOPTIONS, 11858, 0, PTRACE_O_TRACECLONE) = 0
ptrace(PTRACE_POKEUSER, 11858, offsetof(struct user, u_debugreg), 0x400c30) = 0
ptrace(PTRACE_POKEUSER, 11858, offsetof(struct user, u_debugreg) + 56, 0x9) = -1 EINVAL (Invalid argument)
Using gdb I can see
(gdb) break breakpoints_linux_amd64.go:155
(gdb) run
Breakpoint 1, github.com/derekparker/delve/proctl.setHardwareBreakpoint (reg=0, tid=13764, addr=4197424, ~r3=...)
at /home/pnasrat/go/src/github.com/derekparker/delve/proctl/breakpoints_linux_amd64.go:155
155 return PtracePokeUser(tid, dr7addr, dr7)
(gdb) p dr7
$1 = 9
(gdb) p dr7addr
$2 = 904
Delve currently relies on the procid field stored for the M runtime scheduler data structures. Programs built with cgo enabled do not set procid as it is set by runtime functions that are replaced by libc functions.
I've submitted an issue here: golang/go#9914.
Instead of dlv -run you could simply type dlv run, etc... Thoughts?
hello I'm noob and how to compile
"dlv run" should work like "go run" and allow passing a go source file to compile and run. Right now it executes "go build" with no source files, that doesn't work if the current directory contains multiple files implementing "main".
Suggestion: if the first parameter after "dlv run" is "name.go", assume it's the program to run and call "go build" appropriately.
Hi there,
I've finally had some time to play with Delve and I seem to have some problems with printing variables and goroutines on my setup.
I'm using Go 1.4 RC1 on Ubuntu 14.10.
The program I'm trying to debug looks like this:
package main
import "fmt"
func main() {
w:= "world"
fmt.Printf("Hello %s!", w)
}I've also tried var w string = "world" instead of the short assignment but the result is the same unfortunately.
florin@BLMOT-WIN-04 [12:26:23] [~/golang/src/github.com/dlsniper/untitled8]
-> % go build main.go && dlv ./main
Type 'help' for list of commands.
dlv> break main.go:6
Breakpoint set at 0x400c22 for main.main /home/florin/golang/src/github.com/dlsniper/untitled8/main.go:6
dlv> c
new thread spawned 7326
Stopped at: /home/florin/golang/src/github.com/dlsniper/untitled8/main.go:6
1: package main
2:
3: import "fmt"
4:
5: func main() {
6: => w := "world"
7: fmt.Printf("Hello %s!", w)
8: }
dlv> n
Stopped at: /home/florin/golang/src/github.com/dlsniper/untitled8/main.go:7
2:
3: import "fmt"
4:
5: func main() {
6: w := "world"
7: => fmt.Printf("Hello %s!", w)
8: }
dlv> p w
Command failed: decoding dwarf section info at offset 0x29125: unexpected opcode
dlv> goroutines
Command failed: invalid instruction 0x23
dlv> threads
Thread 7326 at 0x42eccb /usr/local/go/src/runtime/proc.c:2861 sysmon
Thread 7296 at 0x400c30 /home/florin/golang/src/github.com/dlsniper/untitled8/main.go:7 main.main
dlv> p
Command failed: not enough arguments
dlv> exit
readline: 0
Would you like to kill the process? [y/n]
y
Detaching from process...
Killing process 7296
[Hope I was of service hunting your bug!]Delve seems to be running ok when there's nothing set as a breakpoint
florin@BLMOT-WIN-04 [12:28:14] [~/golang/src/github.com/dlsniper/untitled8]
-> % go build main.go && dlv ./main
Type 'help' for list of commands.
dlv> c
new thread spawned 7688
Hello world!Command failed: process 7679 has exited
dlv> exit
readline: 0
Would you like to kill the process? [y/n]
y
Detaching from process...
[Could not detach no such process]As a side question, is there any way to have a -debug flag that would allow Delve to print out what's up with the info it tries to understand? I guess it would be helpful to give you what was in memory for this one: Command failed: decoding dwarf section info at offset 0x29125: unexpected opcode. Unfortunately due to severe lack of time I can't add this myself at the moment.
Please let me know if you need any further details to help out with identifying this.
Should follow same semantics as printing a struct, i.e. limiting nesting depth.
After the timeout condition in proctl.timeoutWait is triggered, one of the next
next/step/continue commands will hang with dlv blocked in a wait syscall. I
believe the problem is that in the timeout case timeoutWait leaves a goroutine
running that is still executing a wait syscall. Now we have 2 goroutines which
race for the next SIGTRAP and if the abandoned timeoutWait goroutine
wins dlv hangs.
repo:
$ cat sleep.go
package main
import (
"syscall"
)
func main() {
ts := syscall.Timespec{ Sec: 3 }
syscall.Nanosleep(&ts, nil)
}
$ (echo -e "break syscall.Nanosleep\ncontinue"; yes step) | dlv -run
Instead of going inside the function, nexting when broken at the entry point to a function (think break main.myfunc; continue seems to continue past the function and land at the return address.
As a suggestion, if you move the main package to .../delve/cmd/dlv, you can replace this:
$ go build -o dlv && mv dlv $GOPATH/bin
by this:
$ go install cmd/dlv
and this would also work to the same effect:
$ go get github.com/derekparker/delve/cmd/dlv
The .../cmd/... path is somewhat conventional, FWIW.
When attempting to run with go1.4.2 ( I know docs say you need go 1.4):
make install
I get this error.
import /go/pkg/darwin_amd64/github.com/derekparker/delve/dwarf/util.a: object is [darwin amd64 go1.4.2 X:precisestack] expected [darwin amd64 go1.4 X:precisestack]
Can go1.4.2 be supported, too?
Delve should allow the setting of variables. Command syntax could be something as simple as foo = "bar", or possibly a set command.
When trying to install delve, go get tries to pull dwarf from "github.com/derekparker/delve/vendor/dwarf" but it seems that the package is one level higher "github.com/derekparker/delve/dwarf" it also seems that it trys to fetch another package that is not part of the repo.
package github.com/derekparker/delve/cmd/dlv
imports github.com/derekparker/delve/client/cli
imports github.com/derekparker/delve/command
imports github.com/derekparker/delve/dwarf/frame
imports github.com/derekparker/delve/dwarf/util
imports github.com/derekparker/delve/dwarf/op
imports github.com/derekparker/delve/proctl
imports github.com/derekparker/delve/dwarf/reader
imports golang.org/x/sys/unix
imports github.com/derekparker/delve/vendor/dwarf
imports github.com/derekparker/delve/vendor/dwarf
imports github.com/derekparker/delve/vendor/dwarf: cannot find package "github.com/derekparker/delve/vendor/dwarf" in any of:
/home/action/.parts/packages/go/1.3.3/src/pkg/github.com/derekparker/delve/vendor/dwarf (from $GOROOT)
/home/action/workspace/go/src/github.com/derekparker/delve/vendor/dwarf (from $GOPATH)
package github.com/derekparker/delve/cmd/dlv
imports github.com/derekparker/delve/client/cli
imports github.com/derekparker/delve/command
imports github.com/derekparker/delve/dwarf/frame
imports github.com/derekparker/delve/dwarf/util
imports github.com/derekparker/delve/dwarf/op
imports github.com/derekparker/delve/proctl
imports github.com/derekparker/delve/dwarf/reader
imports golang.org/x/sys/unix
imports github.com/derekparker/delve/vendor/dwarf
imports github.com/derekparker/delve/vendor/elf
imports github.com/derekparker/delve/vendor/elf
imports github.com/derekparker/delve/vendor/elf: cannot find package "github.com/derekparker/delve/vendor/elf" in any of:
/home/action/.parts/packages/go/1.3.3/src/pkg/github.com/derekparker/delve/vendor/elf (from $GOROOT)
/home/action/workspace/go/src/github.com/derekparker/delve/vendor/elf (from $GOPATH)
Delve should return control back to user upon receipt of SIGINT.
Simple program with gorilla/mux dispatching.
dlv program
(dlv) break foo.go:352 # one of the methods dispatched from the mux
(dlv) c
... two threads get spawned...
In separate window curl the url. Program stops. Delve stops and is unresponsive to ^C.
Had to kill -9.
This is Linux ip-10-100-22-97 2.6.32-504.1.3.el6.x86_64 #1 SMP Tue Nov 11 17:57:25 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
go version go1.3.3 linux/amd64
Did the go git today, so should be running most current code.
I have a package that was using (with success) libreadline on Linux, OSX and even Windows (if you managed to get libreadline for Windows). But recently (after Yosemite) I started having problem on OSX (control-C would make my terminal session unusable).
I found this package "github.com/peterh/liner" that is pure-go and works on all platforms (Windows include) with no changes and no dependencies. The history management and command completion is slightly different than libreadline, but it's pretty easy to rework (I did it for http://github.com/gobs/cmd). The only missing feature is that libreadline could automatically expand file names if your completion function returned null)
dlv>
panic: Could not parse SLEB128 value
goroutine 16 [running]:
runtime.panic(0x50ca20, 0xc208120730)
/home/m/Desktop/GOLANG/go1_3_3/go/src/pkg/runtime/panic.c:279 +0xf5
github.com/derekparker/delve/dwarf/util.DecodeSLEB128(0xc20802b2d0, 0xfffffffffffffffe, 0xc200000001)
?:0 +0xef
github.com/derekparker/delve/dwarf/frame.defcfaoffsetsf(0xc20804c980)
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/dwarf/frame/table.go:359 +0x2b
github.com/derekparker/delve/dwarf/frame.executeDwarfInstruction(0xc20804c980)
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/dwarf/frame/table.go:181 +0xca
github.com/derekparker/delve/dwarf/frame.(_FrameContext).ExecuteDwarfProgram(0xc20804c980)
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/dwarf/frame/table.go:148 +0x3c
github.com/derekparker/delve/dwarf/frame.executeCIEInstructions(0xc208018550, 0x7f14f9fe5730)
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/dwarf/frame/table.go:132 +0x154
github.com/derekparker/delve/dwarf/frame.executeDwarfProgramUntilPC(0xc20803b200, 0x400c59, 0x7f14f9e56bb8)
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/dwarf/frame/table.go:138 +0x2b
github.com/derekparker/delve/dwarf/frame.(_FrameDescriptionEntry).EstablishFrame(0xc20803b200, 0x400c59, 0xc208094a1c)
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/dwarf/frame/entries.go:48 +0x31
github.com/derekparker/delve/dwarf/frame.(_FrameDescriptionEntry).ReturnAddressOffset(0xc20803b200, 0x400c59, 0xc20803b200)
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/dwarf/frame/entries.go:52 +0x31
github.com/derekparker/delve/proctl.(_ThreadContext).Next(0xc20800e5a0, 0x0, 0x0)
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/proctl/threads_linux_amd64.go:232 +0x1d6
github.com/derekparker/delve/proctl.(*DebuggedProcess).Next(0xc208004420, 0x0, 0x0)
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/proctl/proctl_linux_amd64.go:254 +0x9e
github.com/derekparker/delve/command.next(0xc208004420, 0xc208120730, 0x0, 0x0, 0x0, 0x0)
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/command/command.go:118 +0x39
main.main()
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/cmd/dlv/main.go:118 +0x915
goroutine 19 [finalizer wait]:
runtime.park(0x415cd0, 0x85a958, 0x84fb49)
/home/m/Desktop/GOLANG/go1_3_3/go/src/pkg/runtime/proc.c:1369 +0x89
runtime.parkunlock(0x85a958, 0x84fb49)
/home/m/Desktop/GOLANG/go1_3_3/go/src/pkg/runtime/proc.c:1385 +0x3b
runfinq()
/home/m/Desktop/GOLANG/go1_3_3/go/src/pkg/runtime/mgc0.c:2644 +0xcf
runtime.goexit()
/home/m/Desktop/GOLANG/go1_3_3/go/src/pkg/runtime/proc.c:1445
goroutine 20 [syscall]:
os/signal.loop()
/home/m/Desktop/GOLANG/go1_3_3/go/src/pkg/os/signal/signal_unix.go:21 +0x1e
created by os/signal.init·1
/home/m/Desktop/GOLANG/go1_3_3/go/src/pkg/os/signal/signal_unix.go:27 +0x32
goroutine 21 [chan receive]:
github.com/derekparker/delve/goreadline.func·001()
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/goreadline/goreadline.go:25 +0x58
created by github.com/derekparker/delve/goreadline.init·1
/home/m/Desktop/GOLANG/gopath/src/github.com/derekparker/delve/goreadline/goreadline.go:33 +0x11a
goroutine 17 [syscall]:
runtime.goexit()
/home/m/Desktop/GOLANG/go1_3_3/go/src/pkg/runtime/proc.c:1445
Just want to know is there any future plan for Windows 32/64 bit support? Or is it the external dependencies the blocker?
I wrote this basic program:
package main
import (
"fmt"
)
func main() {
i := 19
fmt.Println(i)
}
When I try to debug it I get an error:
$ dlv -run
Type 'help' for list of commands.
dlv> b test.go:8
Command failed: Invalid address 0x400c22
I am using go version go1.4 linux/amd64 and ubuntu 14.04.1
With the new "liner" package it is necessary to call liner.Close() to restore the terminal (enable echo, etc.)
While the code does call "defer line.Close()", the line.Close() is not executed when the application terminates because of an error (all the calls to "die() terminate with os.Exit() that doesn't execute any deferred code)
I suggest to either add some "context" do the "die" method (pass the liner or pass some context object if there are other components that need to be released) or use some package that implements "atexit" functionalities.
If you have a preferred method I can work on a pull request.
Should be able to print contents of registers for current thread, and any other arbitrary thread.
Haven't looked into this - but ideally, printing an error type should return the value of its Error method.
Travis seems to always hang on TestNext, not sure why - tests pass locally and on Ubuntu 14.04 vm.
Like in GDB, the list command to list source code in current context,and also some short commands for the respective long commands.
really appreciate your work!
Now that delve supports a majority of types, including complex arrays and structs I think it is worth looking at how to properly display them.
Here are my thoughts so far to get the discussion started.
Support both a human readable format and a separate machine readable output format (for IDE integration).
Standardize when the type name is shown in the human readable format. My first thought is to never show it when using the print command and add a ptype command to print the type of a variable on demand.
Support slice syntax for printing arrays. print x prints the first 64 elements, print x[0] prints the first element, print x[10:12] prints elements 10 to 12 etc.
Support pretty-printing for structs. This could be switched off and on. For example:
Compact:
{f1: Value, f2: Value, f3: {f31: Value, f32: Value, f33: {f331: Value, f332: Value}}, f4: Value}
Pretty:
{
f1: Value
f2: Value
f3: {
f31: Value
f32: Value
f33: {
f331: Value
f332: Value
}
}
}
Also on info locals. info args doesn't crash, but doesn't show any output, though there is an arg to the function. And finally, the p command always reports Command failed: could not read memory.
new thread spawned 5891
Type 'help' for list of commands.
(dlv) c
INFO[0003] Request params params=[{"Key":"accountid","Value":"85655878-c13d-4a0e-b94b-d5c2c1247b6a"}]
new thread spawned 6919
new thread spawned 7171
thread context changed from 5891 to 7171
current loc: safex/controllers.CreateDomain /Volumes/Pouch/Users/russegan/dev/go/src/safex/controllers/domains.go:18
13: domain := models.Domain{}
14: if c.Bind(&domain) {
15: jsonParams, _ := json.Marshal(c.Params)
16: log.WithField("params", string(jsonParams)).Info("Request params")
17: runtime.Breakpoint()
=> 18: if accountId := c.Params.ByName("accountid"); accountId != "" {
19: domain.AccountId = accountId
20: }
21: if err := appContext.Db().Create(&domain).Error; err != nil {
22: log.WithFields(log.Fields{"err": err}).Panic("Failed to create domain")
23: }
(dlv) info locals
panic: runtime error: index out of range
goroutine 1 [running, locked to thread]:
github.com/derekparker/delve/proctl.readMemory(0xc2085cf680, 0x0, 0x42ceb48, 0x0, 0x0, 0x0, 0x0, 0x0)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/proctl/threads_darwin.go:73 +0xf8
github.com/derekparker/delve/proctl.(*ThreadContext).readMemory(0xc2085cf680, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/proctl/variables.go:915 +0xb7
github.com/derekparker/delve/proctl.(*ThreadContext).readString(0xc2085cf680, 0x0, 0x0, 0x0, 0x0, 0x0)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/proctl/variables.go:711 +0x1ee
github.com/derekparker/delve/proctl.(*ThreadContext).extractValueInternal(0xc2085cf680, 0x0, 0x0, 0x0, 0xc208031980, 0x41ac680, 0xc20868afc0, 0x1, 0x1, 0x0, ...)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/proctl/variables.go:643 +0x70a
github.com/derekparker/delve/proctl.(*ThreadContext).extractValueInternal(0xc2085cf680, 0x0, 0x0, 0x0, 0xc208031980, 0x41ac680, 0xc20868af60, 0x1, 0x0, 0x0, ...)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/proctl/variables.go:652 +0x9a7
github.com/derekparker/delve/proctl.(*ThreadContext).extractValueInternal(0xc2085cf680, 0xc208239f3f, 0x5, 0x11248a, 0xc20809b600, 0x41a5d00, 0xc20868d4a0, 0x1, 0x0, 0x0, ...)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/proctl/variables.go:634 +0x15ea
github.com/derekparker/delve/proctl.(*ThreadContext).extractValue(0xc2085cf680, 0xc208239f3f, 0x5, 0x11248a, 0x0, 0x41a5d00, 0xc20868d4a0, 0xc2085fb701, 0x0, 0x0, ...)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/proctl/variables.go:597 +0xb8
github.com/derekparker/delve/proctl.(*ThreadContext).extractVariableFromEntry(0xc2085cf680, 0xc20868d440, 0x0, 0x0, 0x0)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/proctl/variables.go:530 +0x55f
github.com/derekparker/delve/proctl.(*ThreadContext).variablesByTag(0xc2085cf680, 0x34, 0x0, 0x0, 0x0, 0x0, 0x0)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/proctl/variables.go:945 +0x238
github.com/derekparker/delve/proctl.(*ThreadContext).LocalVariables(0xc2085cf680, 0x0, 0x0, 0x0, 0x0, 0x0)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/proctl/variables.go:366 +0x5d
github.com/derekparker/delve/command.info(0xc208032360, 0xc2085cfa30, 0x1, 0x1, 0x0, 0x0)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/command/command.go:283 +0x9cd
github.com/derekparker/delve/client/cli.Run(0xc20800a010, 0x1, 0x1)
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/client/cli/cli.go:114 +0xa9d
main.main()
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/cmd/dlv/main.go:52 +0x330
goroutine 5 [syscall]:
os/signal.loop()
/usr/local/Cellar/go/1.4.2/libexec/src/os/signal/signal_unix.go:21 +0x1f
created by os/signal.init·1
/usr/local/Cellar/go/1.4.2/libexec/src/os/signal/signal_unix.go:27 +0x35
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/Cellar/go/1.4.2/libexec/src/runtime/asm_amd64.s:2232 +0x1
goroutine 8 [chan receive]:
github.com/derekparker/delve/client/cli.func·001()
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/client/cli/cli.go:82 +0x65
created by github.com/derekparker/delve/client/cli.Run
/Volumes/Pouch/Users/russegan/dev/go/src/github.com/derekparker/delve/client/cli/cli.go:87 +0x616
Instead of info sources, just type sources. None of those commands of info conflict so it shouldn't be an issue, and would be less typing. Thoughts, concerns?
when stepping the terminal scrollback is huge
http://pastebin.com/raw.php?i=ZZxNbjVf
it would be nice if the scrollback either disappear like in a ncurses app, or be smaller, let's say 1 row per step, not 14 rows per step every time
by the way, thanks for the great debugger. 60% of the time, it works every time
Thanks for working on this!
I just wanted to try it out, but it seems like OSX is not supported yet?
$ go get -u github.com/derekparker/delve/cmd/dlv
go build github.com/derekparker/delve/proctl: no buildable Go source files in /Users/felix/code/go/src/github.com/derekparker/delve/proctl
# github.com/derekparker/delve/goreadline
38: error: use of undeclared identifier 'rl_catch_sigwinch'
38: error: use of undeclared identifier 'rl_resize_terminal'; did you mean 'rl_reset_terminal'?
A small section mentioning the native dependencies the package uses would be nice. Specifically libreadline-dev for Ubuntu.
A user would only see this dependency once they try the command, and would need to know how to install it for their system.
I downloaded Go 1.4.1 and built my test app - it worked. Then I did
go get github.com/derekparker/delve/cmd/dlv
dlv path/to/my/app
continue
It prints "new thread spawned 11399" and hangs. ^C doesn't work. The app isn't running.
I tried setting breakpoints, etc, but it always hangs after the first "continue".
Right now delve creates readline history file in cwd, but this is not acceptable going forward.
When stopped in a debug session, have a command to show source code around the current location this (or any arbitrary) thread is stopped at. Should have a default (5 lines above/below or similar) but also accept an argument to display more source code context.
package main
func count(ch chan <- int) {
x := 0
for {
ch <- x
tmp := x
tmp += 1
x = tmp
}
}
func main() {
ch := make(chan int)
go count(ch)
for {
====> <- ch
}
}
next over the <- ch in main will lock up dlv (hangs in a wait4 syscall, with 2 of the 3 threads in stopped state).
Running dlv in my terminal prevents the terminal from displaying typed/pasted input from showing up when typed after dlv exits. Typed input still is displayed in dlv, even if its restarted after the terminal's input no longer displays. I'm using OSX 10.9 and iTerm2 (1.0.0.20140629). Verified this also happens in Terminal (2.4 326).
The terminal is still receiving the input, because I can execute commands. The input text just isn't displayed outside of dlv.
I found I needed to run 'stty sane' to restore input being displayed. 'stty echo' also works.
When i do 'go get github.com/derekparker/delve/cmd/dlv' it fails with the following error
../../derekparker/delve/proctl/proctl.go:31: undefined: BreakPoint
../../derekparker/delve/proctl/proctl.go:32: undefined: BreakPoint
Correct me if I am wrong, but your tool only works in 64-bit systems. I tried to install dlv via go get and got this error:
go build github.com/derekparker/delve/proctl: no buildable Go source files in /home/user/go/src/github.com/derekparker/delve/proctl
AFAIK those who had 64-bit O.S. got dlv working properly.
P.S: I have libreadline installed.
It is possible to set a breakpoint in a multi-line variable declaration, at which point the variables have not yet been initialized. Calling info locals at that point will render undefined behavior and may result in a panic.
11:59 ~/code/go $ cat hello.go
package main
// #include <stdio.h>
// #include <stdlib.h>
// static void hack(char *str) { printf("%s", str); }
import "C"
import "unsafe"
func main() {
cstr := C.CString("hello world!\n")
defer C.free(unsafe.Pointer(cstr))
C.hack(cstr)
}
11:59 ~/code/go $ go build hello.go
11:59 ~/code/go $ dlv ./hello
[Could not launch program: decoding dwarf section info at offset 0x0: too short]
11:59 ~/code/go $
dlv
Delve version 0.5.0.beta
flags:
-v - Print version
Invoke with the path to a binary:
dlv ./path/to/prog
or use the following commands:
run - Build, run, and attach to program
attach - Attach to running process
12:00 ~/code/go $ dlv -v -
flag provided but not defined: -v
Usage of dlv:
12:00 ~/code/go $ go version
go version go1.4 darwin/amd64
12:00 ~/code/go $ uname -a
Darwin Thunder 14.1.0 Darwin Kernel Version 14.1.0: Mon Dec 22 23:10:38 PST 2014; root:xnu-2782.10.72~2/RELEASE_X86_64 x86_64
12:01 ~/code/go $
A traced program will read its stdin from os.DevNull instead of os.Stdin, since in proctl.Launch() it is only stderr and stdout. I can't figure out the reason for this, and simply adding proc.Stdin = os.Stdin in the Launch() function will make a simple test program behave as expected.
Forked from issue #88
/cc @ironcladlou
Hi @derekparker,
First of all, Thank you for this!
While I haven't played with it yet, I plan to do so this weekend.
If all things work good enough, I'd be interesting in integrating it with the Go plugin for IntelliJ IDEA.
As I haven't seen anything that could help out IDEs do the interfacing part so I'd like to ask if there's any plans for this. I could potentially help out by defining an HTTP interface for it and just pipe all the commands to the debugger via HTTP calls / JSON responses. A side effect of this, then it could allow creating web interfaces for this.
What do you think? Does it make sense to you? If you'd like to chat, please drop me a mention on Gitter.
Kind regards
Tests are failing on master and I have not yet found a cause.
new thread spawned 1476
new thread spawned 1477
new thread spawned 1487
new thread spawned 1488
Hello, World!
new thread spawned 1497
new thread spawned 1498
new thread spawned 1508
new thread spawned 1534
new thread spawned 1535
new thread spawned 1536
foo
Hello, World!
foo
foo
Hello, World!
new thread spawned 1545
new thread spawned 1555
new thread spawned 1556
new thread spawned 1565
--- FAIL: TestVariableFunctionScoping (1.22s)
proctl_test.go:52: Continue() returned an error : could not get registers could not get registers no such process
new thread spawned 1580
new thread spawned 1581
FAIL
FAIL github.com/derekparker/delve/proctl 10.588s
$ dlv -run
[Could not start process: fork/exec ./debug: permission denied]
$ chmod +x ./debug
$ dlv -run
[Could not start process: fork/exec ./debug: permission denied]
Overall improve handling of process natural death.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.