Delve is a debugger for the Go programming language.

Overview

Delve

license GoDoc Build Status

The GitHub issue tracker is for bugs only. Please use the developer mailing list for any feature proposals and discussions.

About Delve

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.

Comments
  • WIP: Refactor to HTTP client/server model

    WIP: Refactor to HTTP client/server model

    NOTE This is a work-in-progress, and the PR is to facilitate ongoing design discussion. This PR is intended to address #22.

    Goals

    1. Introduce an HTTP server using net.Listener to provide a JSON-based remote API to the debugger
      1. Support RESTful operations for state retrieval and commands
      2. Support a long-polling watch requests to support event notifications
    2. Provide a Go client interface and default HTTP implementation
    3. Refactor the terminal to be a pure API client consumer

    The original PR is based on this comment on #22.

    opened by ironcladlou 122
  • OS X: cannot get thread count

    OS X: cannot get thread count

    Please answer the following before submitting your issue:

    Note: Please include any substantial examples (debug session output, stacktraces, etc) as linked gists.

    1. What version of Delve are you using (dlv version)? Delve Debugger Version: 0.11.0-alpha Build: fb8388ab2e50ca28ef9a83c73c329f8d0b6234d9

    2. What version of Go are you using? (go version)? go version go1.7.1 darwin/amd64

    3. What operating system and processor architecture are you using? OS X 10.12.1 Beta (16B2333a) (developer beta 2 Sept 28)

    4. What did you do? Tried to debug my app from within Visual Studio Code and from the command line with the same results

    5. What did you expect to see? Debugging goodness

    6. What did you see instead? From VS Code: 2016/09/29 06:26:35 server.go:71: Using API v1 2016/09/29 06:26:35 debugger.go:61: launching process with args: [./debug -race -tags debug] could not launch process: could not get thread count

      From terminal: [email protected] [6:17:20]: dlv debug could not launch process: could not get thread count

    I believe it may be related to the upgrade from Sierra beta 1 to beta 2. I was debuggin a'plenty earlier in the afternoon on my MacBook which was still on beta 1, but when I tried on the iMac I got the above failure. The iMac is beta 2. I've since upgraded the MacBook to beta 2 (this was before I realized there may be a problem) and now I get the same error on the MacBook.

    kind/bug help wanted os/macOS area/proc 
    opened by scaba 82
  • could not launch process: EOF

    could not launch process: EOF

    Please answer the following before submitting your issue:

    Note: Please include any substantial examples (debug session output, stacktraces, etc) as linked gists.

    1. What version of Delve are you using (dlv version)?
    Delve Debugger
    Version: 1.0.0
    Build: db435c184eb79976087fc0cb36c2867c737a9066
    
    1. What version of Go are you using? (go version)?
    go env
    GOARCH="amd64"
    GOBIN=""
    GOCACHE="/Users/dingwenjiang/Library/Caches/go-build"
    GOEXE=""
    GOHOSTARCH="amd64"
    GOHOSTOS="darwin"
    GOOS="darwin"
    GOPATH="/Users/dingwenjiang/go"
    GORACE=""
    GOROOT="/usr/local/go"
    GOTMPDIR=""
    GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
    GCCGO="gccgo"
    CC="clang"
    CXX="clang++"
    CGO_ENABLED="1"
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ly/7p11f6gn5v71sspkdwx4qhgc0000gn/T/go-build573955664=/tmp/go-build -gno-record-gcc-switches -fno-common"
    
    1. What operating system and processor architecture are you using?
    sw_vers
    ProductName:	Mac OS X
    ProductVersion:	10.13.4
    BuildVersion:	17E199
    
    
    uname -a
    Darwin dingwenjiangdeMacBook-Pro.local 17.5.0 Darwin Kernel Version 17.5.0: Mon Mar  5 22:24:32 PST 2018; root:xnu-4570.51.1~1/RELEASE_X86_64 x86_64
    
    1. What did you do?
    go get -u github.com/derekparker/delve/cmd/dlv
    go build -gcflags "-N -l" -a github.com/golang/example/hello
    $GOPATH/bin/dlv exec hello
    could not launch process: EOF
    
    1. What did you expect to see?
    To dlv start a debug session
    
    1. What did you see instead?
    could not launch process: EOF
    
    opened by warjiang 78
  • dlv exec throws

    dlv exec throws "could not launch process: EOF"

    Please answer the following before submitting your issue:

    Note: Please include any substantial examples (debug session output, stacktraces, etc) as linked gists.

    1. What version of Delve are you using (dlv version)?
    Delve Debugger
    Version: 1.0.0-rc.2
    Build: $Id: 5c7676404d10d52e16be57fea744a7312b831f0c $
    
    1. What version of Go are you using? (go version)?
    go env
    GOARCH="amd64"
    GOBIN=""
    GOEXE=""
    GOHOSTARCH="amd64"
    GOHOSTOS="darwin"
    GOOS="darwin"
    GOPATH="/Users/pablo.molnar"
    GORACE=""
    GOROOT="/usr/local/Cellar/go/1.9.2/libexec"
    GOTOOLDIR="/usr/local/Cellar/go/1.9.2/libexec/pkg/tool/darwin_amd64"
    GCCGO="gccgo"
    CC="clang"
    GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/v9/yp3rfr6n41lgnfl0g6c4wxqw385cfp/T/go-build535672296=/tmp/go-build -gno-record-gcc-switches -fno-common"
    CXX="clang++"
    CGO_ENABLED="1"
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    
    1. What operating system and processor architecture are you using?
    sw_vers
    ProductName:	Mac OS X
    ProductVersion:	10.13.1
    BuildVersion:	17B48
    
    uname -a
    Darwin MACC02TX14FHTDD 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017; root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
    
    1. What did you do?
    go get -u github.com/derekparker/delve/cmd/dlv
    go build -gcflags "-N -l" -a github.com/golang/example/hello
    $GOPATH/bin/dlv exec hello
    could not launch process: EOF
    
    1. What did you expect to see? To dlv start a debug session

    2. What did you see instead? could not launch process: EOF

    This is a new MacBook Pro (MacBookPro14,3) with all the updates. Old MacBook Pro (MacBookPro11,5) with all updates works fine... Not working through the terminal nor IntelliJ IDEA Go plugin

    kind/bug os/macOS area/proc/gdbserial 
    opened by pablomolnar 64
  • could not launch process: decoding dwarf section info at offset 0x0: too short

    could not launch process: decoding dwarf section info at offset 0x0: too short

    When I brew install go ,and go get -u -v github.com/derekparker/delve/cmd/dlv , I debug the program, it throw Exception as following (while it is ok when I run the program, ): GOROOT=/usr/local/Cellar/go/1.10/libexec #gosetup GOPATH=/Users/friends/Documents/VirtualMachine/share/gopath #gosetup /usr/local/Cellar/go/1.10/libexec/bin/go build -gcflags "-N -l" -tags nopkcs11 "-ldflags=-linkmode internal" -o /private/var/folders/cg/mwzlhrjs5y55ny553g6xz9tr0000gn/T/___peer_server -gcflags "all=-N -l" /Users/friends/Documents/VirtualMachine/share/gopath/src/github.com/hyperledger/fabric/peer/main.go #gosetup "/Applications/GoLand 1.0 EAP.app/Contents/plugins/intellij-go-plugin/lib/dlv/mac/dlv" --listen=localhost:50170 --headless=true --api-version=2 --backend=native exec /private/var/folders/cg/mwzlhrjs5y55ny553g6xz9tr0000gn/T/___peer_server -- node start --peer-chaincodedev=true -orderer 192.168.120.189:7050 #gosetup could not launch process: decoding dwarf section info at offset 0x0: too short

    Delve Debugger Version: 1.0.0 Build: $Id: c98a142125d0b17bb11ec0513bde346229b5f533 $

    go version go1.10 darwin/amd64

    MacOS Darwin

    opened by friends110110 61
  • [WIP] Windows support

    [WIP] Windows support

    Initial work on porting Delve to support Windows.

    There's a lot more to do before this is ready to be merged, but most of the core infrastructure for Windows support is in place, and some basic Delve scenarios are working in simple scenarios (launching, setting breakpoints, continuing, breaking on breakpoints, inspecting registers, seeing sources, inspecting locals, exiting, etc.).

    Fixes #198.

    opened by lukehoban 46
  • FreeBSD initial support

    FreeBSD initial support

    This pull request adds initial support for FreeBSD. It's primarily based on fbsd branch from: github.com:asomers/delve.git, just fixes few critical bugs and adds few new functions.

    It passes almost all tests (281 of 288), except few "Concurrency" ones, but I believe it's not a bug, but a natural behavior for FreeBSD and these tests should be slightly changed.

    E.g. on "TestBreakpointCounts" two threads are expected to hit same breakpoint 100 times each. In FreeBSD, when main thread exits, all "child" threads are not triggering TRAP signals anymore, process just finishes. That's why when main thread reaches 100 breakpoint hits and exits, child thread will never reach 100 and stops somewhere around 95. Sometimes, when child thread is faster and completes BP race first, we can see this test as PASSED.

    Other than that it works fine.

    ref: https://github.com/go-delve/delve/issues/213

    Thanks.

    opened by rayrapetyan 43
  • Support for OSX

    Support for OSX

    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'?
    
    enhancement 
    opened by felixge 42
  • proc.(*Process).Continue skips breakpoints [WIP]

    proc.(*Process).Continue skips breakpoints [WIP]

    This is a fix for the problem unearthed by PR #255, it is submitted for discussion, not definitive.

    There are two problems with (*Process).Continue

    1. The first is that between the time one breakpoint is triggered and the point where we loop over all threads and Halt eacho one the second goroutine may hit the breakpoint too, this second hit gets lost
    2. The second problem is that the way Continue resumes the process has a race condition with the tracee

    Let's that thread A hit the breakpoint and thread B was sleeping when Continue called Halt on it. After we finish processing the breakpoint on A we call Continue again, Continue then loops through all threads, it calls resume on B, then moves onto thread A, sees that it's on a breakpoint so it calls (*Thread).Step(). If thread B happens to get to the breakpoint while (*Thread).Step on thread A is happening the breakpoint gets skipped, because we temporarily cleared it.

    You can test this by reverting the changes and running TestBreakpointCounts. The fact that multiple breakpoints can be hit simultaneously needs to be propagated all the way to the client, either by changing CurrentBreakpoint in State to a slice or by returning one breakpoint at a time in Debugger.

    opened by aarzilli 41
  • service/dap: Support for replay and core modes

    service/dap: Support for replay and core modes

    This PR aims to add support for rr replay and core actions from the DAP layer. This basically encloses the following:

    New launch modes: replay and core

    The following modes are added:

    • replay: Replays an rr trace, allowing backwards flows (reverse continue and stepback). Requires a traceDirPath property on launch.json pointing to a valid rr trace directory. Equivalent to dlv replay <tracedir> command.
    • core: Replays a core dump file, showing its callstack and the file matching the callsite. Requires a coreFilePath property on launch.json pointing to a valid coredump file. Equivalent to dlv core <exe> <corefile> command.

    Dependencies

    To achieve this the following additional changes were made:

    • Implement the onStepBackRequest and onReverseContinueRequest methods on service/dap
    • Adapt onLaunchRequest with the requried validations and logic for these new modes
    • Use CapabilitiesEvent responses to enable the StepBack controls on the supported scenarios (see dicussion here)
    • Add the corresponding launch.json support on vs code: https://github.com/golang/vscode-go/pull/1268
    priority/P1 area/dap needs-rebase 
    opened by lggomez 35
  • IDE interfaces

    IDE interfaces

    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

    enhancement 
    opened by dlsniper 33
  • proc/gdbserver: set child process pgrp as foreground group

    proc/gdbserver: set child process pgrp as foreground group

    Newer versions of debugserver (which contain [1]) will spawn the target process on a new process group, when we detect that this happen, and we are a headless instance and stdin is a tty, make the child process' process group the controlling group for the terminal.

    [1] https://reviews.llvm.org/rG33ac4fddc7906ba712c50cd3a9b02ae041d751ab

    opened by aarzilli 0
  • proc: extend macOS workaround to amd64

    proc: extend macOS workaround to amd64

    Go change 064f34f (which exists in Go 1.19.2 and following) removed the pagezero_size option from linker calls (because it is deprecated). This expanded the problem that exists on darwin/arm64 as well as PIE builds on darwin/amd64 to all darwin/amd64 builds.

    This problem is described on: https://github.com/golang/go/issues/25841.

    This commit extends the darwin/arm64 workaround to darwin/amd64.

    Fixes #3194

    opened by aarzilli 0
  • Test windows/arm64 pipeline

    Test windows/arm64 pipeline

    This PR does all the wiring so windows/arm64 gets tested on the TeamCity pipeline using my on-prem builder.

    This is the list of changes:

    • Update test_windows.ps1 so it only writes files (namely the Go binary and source code, gcc toolchain and procdump) inside the TeamCity agent home. This is necessary because the on-prem agent is running as a low-privileged service which only have read/write access to its home directory.
    • Mingw-w64 toolchain still not supports windows/arm64. I'm using a LLVM based mingw-64 toolchain instead, which is inline with what's using Go to test on this platform.
    • Drop the exp.winarm64 build tag.
    • Update TestLaunchRequestWithRelativeExecPath so it does not fail if symlinks can't be created, but just skip the test. My on-prem agent does not have permissions to create symlinks (on purpose), so that test can't be executed.
    • Skip TestCgoStacktrace. CGO stack traces are broken on windows/arm64. It can be investigated in a follow-up issue.
    • Function calls are flaky, so I've marked them as not implemented.

    @aarzilli @derekparker

    opened by qmuntal 5
  • Wrong position after step in on mac

    Wrong position after step in on mac

    1. What version of Delve are you using (dlv version)?
    Delve Debugger
    Version: 1.9.1
    Build: $Id: d81b9fd12bfa603f3cf7a4bc842398bd61c42940 $
    
    1. What version of Go are you using? (go version)?
    go version 1.19.3 darwin/amd64
    
    1. What operating system and processor architecture are you using?

    MacOS 12.5.1

    1. What did you do?

    Debugged the program

    package main
    
    import "fmt"
    import _ "k8s.io/cli-runtime/pkg/resource"
    
    func main() {
    	f() // break here
    }
    
    func f() {
    	fmt.Println("ok")
    }
    

    Once breakpoint is reached stepped twice.

    1. What did you expect to see?

    Debugger stops somewhere inside the fmt package.

    1. What did you see instead?

    Debugger stops in runtime (proc.go). Log: https://gist.github.com/nd/0445e4ed453155388cca9594ab37bd79.

    Got wrong position in go1.19.2+ and go1.18.7+, works as expected in go1.19.1 and go1.18.6.

    Also happens if k8s import is replaced with cgo:

    package main
    
    /*
    #cgo LDFLAGS: -framework CoreFoundation
    #cgo LDFLAGS: -framework CFNetwork
    #include <CFNetwork/CFProxySupport.h>
    */
    import "C"
    import "fmt"
    
    func main() {
    	f() // break here
    }
    
    func f() {
    	fmt.Println("ok")
    }
    

    Works as expected if the cgo import is removed.

    kind/bug os/macOS area/proc arch/amd64 
    opened by nd 3
  • Debugger stops at breakpoint in a loop only once (Windows Arm64)

    Debugger stops at breakpoint in a loop only once (Windows Arm64)

    1. dlv version

    Delve Debugger
    Version: 1.9.1
    Build: $Id: d81b9fd12bfa603f3cf7a4bc842398bd61c42940 $
    

    2. go version go version go1.19.3 windows/arm64

    3. Operating system and processor architecture

    Edition	       Windows 11 Pro
    Version	       22H2
    OS build	       22621.521
    System type  64-bit operating system, ARM-based processor
    

    6. Steps to reproduce

    • Install delve for Windows arm64 go install -tags exp.winarm64 github.com/go-delve/delve/cmd/dlv

    • Create sample.go file with the outlined below content `package main

      import ( "fmt" )

      func main() { length, capacity, y := 1000, 2000, 3 AllResults := make([]int, length, capacity) for i := 0; i < length; i++ { result := i / y // Hi there fmt.Println(result) AllResults[i] = result } j := 0 fmt.Println(j) }`

    • Start debug client: dlv debug sample.go

    • Add breakpoint inside loop: (dlv) break sample.go:12

    • Continue debug session (dlv) continue (debugger stops at breakpoint)

    • Continue debug session further (dlv) continue

    7. Expected result The debugger stops at the breakpoint in every cycle in a loop.

    8. Actual result The debugger stops at the breakpoint only in first cycle of the loop.

    example

    kind/bug os/windows arch/arm64 
    opened by sergunya 7
  • *: early fixes for go1.20

    *: early fixes for go1.20

    • updated go/packages to support new export format

    • rewrite testinline.go fixture because the compiler got too smart with constant folding

    • temporarily disable staticcheck on go1.20 because it doesn't support the new export format.

    • workaround for go.dev/cl/429601

    opened by aarzilli 1
Releases(v1.9.1)
Owner
null
Rdebug — Real Debugger

RDebug - Real Debugger Translation 中文 1. Introduction Rdebug is an open source tool chain that focusing on efficiency of daily developing, testing and

DiDi 1.1k Nov 21, 2022
Learngo - The purpose of this repository is to teach the basics of go programming language.

Learn Go Programming The purpose of this repository is to teach the basics of go programming language. Go programming language is developed and active

Jithu Mohandas 0 Jan 3, 2022
Colored pretty printer for Go language

pp Colored pretty printer for Go language Usage Just call pp.Print(). import "github.com/k0kubun/pp" m := map[string]string{"foo": "bar", "hello": "w

Takashi Kokubun 1.5k Nov 20, 2022
groqfmt is a formatter for the GROQ query language

groqfmt groqfmt is a formatter for the GROQ query language. Usage Either: groqfmt INPUT > OUTPUT or: cat INPUT | groqfmt > OUTPUT or cat INPUT | groqf

Sanity 9 Oct 6, 2022
Gomon - Go language based system monitor

Copyright © 2021 The Gomon Project. Welcome to Gomon, the Go language based system monitor Welcome to Gomon, the Go language based system monitor Over

zosmac 3 Nov 18, 2022
Sand is the next, versatile, high-level compiled or interpreted language that's easy to learn and performant to run.

Sand is the newest, dynamically typed, interpreted programming language. Table of Contents History Project Stats History Sand was created as part of @

Neuron AI 4 Mar 13, 2022
Logger - Go language is interface-oriented to implement an asynchronous log writing program

logger日志库 1、安装 go get github.com/staryjie/[email protected] 2、使用 示例: package main import ( "github.com/staryjie/logger" "time" ) func initLogger(name,

StaryJie 0 Jan 4, 2022
Go-mix - Both a tutorial paper and a library of classic TAOCP algorithms in the Go language

MIX golang This package is both a tutorial paper and a library of classic TAOCP

Andrew Astakhov 0 Jul 25, 2022
Delve is a debugger for the Go programming language.

The GitHub issue tracker is for bugs only. Please use the developer mailing list for any feature proposals and discussions. About Delve Installation L

Derek Parker 541 Nov 28, 2022
GUI frontend for Delve

GUI frontend for Delve

Alessandro Arzilli 1.1k Nov 21, 2022
GUI frontend for Delve

Gdlv is a graphical frontend to Delve for Linux, Windows and macOS. Demo video here. Setup First install the current version of Delve, following Delve

Alessandro Arzilli 1.1k Nov 21, 2022
Go test command line interface for dlv(delve)

What does it do? Delver makes the command line interface for starting dlv the same as the one used in go test Example Say you're using this when devel

Johan Håkansson 0 Jan 7, 2022
Floppa programming language inspired by the brainf*ck programming language. Created just for fun and you can convert your brainf*ck code to floppa code.

Floppa Programming Language Created just for fun. But if you want to contribute, why not? Floppa p.l. inspired by the brainf*ck programming language.

null 19 Oct 20, 2022
T# Programming Language. Something like Porth, Forth but written in Go. Stack-oriented programming language.

The T# Programming Language WARNING! THIS LANGUAGE IS A WORK IN PROGRESS! ANYTHING CAN CHANGE AT ANY MOMENT WITHOUT ANY NOTICE! Something like Forth a

T# 92 Jun 29, 2022
Yayx programming language is begginer friendly programming language.

Yayx Yayx programming language is begginer friendly programming language. What have yayx: Easy syntax Dynamic types Can be compiled to outhers program

null 1 Dec 27, 2021
Yayx programming language is begginer friendly programming language.

Yayx Yayx programming language is begginer friendly programming language. What have yayx: Easy syntax Dynamic types Can be compiled to outhers program

Yayx Programming Language 7 May 20, 2022
GAPID: Graphics API Debugger

GAPID: Graphics API Debugger

Google 2.1k Nov 23, 2022
Rdebug — Real Debugger

RDebug - Real Debugger Translation 中文 1. Introduction Rdebug is an open source tool chain that focusing on efficiency of daily developing, testing and

DiDi 1.1k Nov 21, 2022
Interactive Go interpreter and debugger with REPL, Eval, generics and Lisp-like macros

gomacro - interactive Go interpreter and debugger with generics and macros gomacro is an almost complete Go interpreter, implemented in pure Go. It of

Massimiliano Ghilardi 2k Nov 18, 2022
ROFL eXtension Debugger - for League of Legends replay files

ROFLXD - ROFL eXtension Debugger This is an incomplete project. The original goal of this project was to convert GLR replays to a form that was playab

Fraxiinus 1 Oct 10, 2022