The go debugger "dlv" just hangs

[chx]

go get -u github.com/derekparker/delve/cmd/dlv
go get -v github.com/gohugoio/hugo
cd $GOPATH/src/github.com/gohugoio/hugo
go  build -gcflags="-N -l"
dlv exec ./hugo -- -s /path/to/the/projectdir

this hangs on WSL and runs fine under Fedora and Debian. Pressing Ctrl+C runs hugo as normal but that skips the debugger.

strace -o log -f dlv exec ./hugo -- -s ~/www/usbc doesn't lead to anything usable: could not launch process: fork/exec ./hugo: operation not permitted and it's really stubbornly not, even sudo won't change this outcome.

[therealkenc]

Your repro steps worm after (an assumed) sudo apt install golang-go. But the nature of the fail had me curious enough, so...

$ sudo add-apt-repository ppa:gophers/archive
$ sudo apt-get update
$ sudo apt-get install golang-1.9-go
$ export PATH=$PATH:/usr/lib/go-1.9/bin  # guh seriously 🙄
$ mkdir -p $HOME/go
$ export GOPATH=$HOME/go
$ export PATH=$PATH:$GOPATH/bin
$ go version
go version go1.9.4 linux/amd64
$ dlv version
Delve Debugger
Version: 1.0.0
Build: $Id: c98a142125d0b17bb11ec0513bde346229b5f533 $
$ go get -u github.com/derekparker/delve/cmd/dlv
$ go get -v github.com/gohugoio/hugo
$ cd $GOPATH/src/github.com/gohugoio/hugo
$ go  build -gcflags="-N -l"
$ dlv exec ./hugo -- -s /path/to/what/projectdir

Confirmed your outcome on 17107. I think you might be looking at #2028 PTRACE_TRACEME, but I haven't taken the time to prove the hypothesis.

[chx]

Well, if you installed the latest go for this issue, I can install the latest rr. The information provided in the crash looks very promising.

dlv exec --backend rr ./hugo -- -s ~/www/usbc

rr: Saving execution to trace directory `/home/chx/.local/share/rr/hugo-0'.
[FATAL /home/roc/rr/rr/src/Task.cc:2645:spawn() errno: EINVAL] PTRACE_SEIZE failed for tid 26718
=== Start rr backtrace:
rr(_ZN2rr13dump_rr_stackEv+0x28)[0x55ae48]
rr(_ZN2rr15notifying_abortEv+0x47)[0x55aec7]
rr(_ZN2rr4Task5spawnERNS_7SessionERKNS_8ScopedFdERKNS_11TraceStreamERKSsRKSt6vectorISsSaISsEESF_i+0x707)[0x545647]
rr(_ZN2rr13RecordSessionC1ERKSsRKSt6vectorISsSaISsEES7_NS0_16SyscallBufferingENS_7BindCPUE+0x1ad)[0x4c7c1d]
rr(_ZN2rr13RecordSession6createERKSt6vectorISsSaISsEES5_NS0_16SyscallBufferingENS_7BindCPUE+0x818)[0x4c85d8]
rr(_ZN2rr13RecordCommand3runERSt6vectorISsSaISsEE+0x944)[0x4be474]
rr(main+0x244)[0x450b74]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f41f9750830]
rr[0x45105f]
=== End rr backtrace
could not launch process: signal: aborted (core dumped)

[chx]

Closing in favor #2028 , dlv by default uses native and as visible, rr fails too. Nothing to do with dlv itself.

[therealkenc]

Thanks. Hopefully the devs can weigh in on your question over there because PTRACE_SEIZE was #548 and should (might?) be under control. My #2028 ref was mostly a wild ass guess. There is a cornucopia of ptrace() flags and it is hard to tell which work, which partially work, which don't work, and which are red herrings (because strace on debuggers calling ptrace() is problematic on a good day). But either way, you could do worse than wait for lldb to light up and try again then. At least you'll be in good company.