Delve: Cannot debug non-main package error when debuggin folder directly under GOPATH

Created on 17 Jul 2018  路  3Comments  路  Source: go-delve/delve

  1. What version of Delve are you using (dlv version)?
    1.0.0
  2. What version of Go are you using? (go version)?
    Go 1.9
  3. What operating system and processor architecture are you using?
    windows/amd64
  4. What did you do?
    Tried to debug a package that is directly under the GOPATH using go delve packagename
  5. What did you expect to see?
    breakpoints hit
  6. What did you see instead?
    > Can not debug non-main package
    Process exiting with code: 1

Repro Steps:

  • Create 2 Go files with the below file paths
    GOPATH -> src -> testing -> hello.go
    GOPATH -> src -> testing -> subfolder -> sub.go
  • Add the below sample content in both files
package main

import "fmt"

func main() {
    fmt.Println("hello")
}
  • In a terminal run the below. Note that it fails with "Can not debug non-main package"
cd $GOPATH/src/testing
dlv debug testing
  • Next run the below. Note that the debugging runs just file
dlv debug testing/subfolder

Most helpful comment

No problem, I actually learned a lot researching this issue :)

All 3 comments

Hey @ramya-rao-a, I can reproduce this, it seems to be a permissions issue, the created binary doesn't have execution permissions and Delve can't run it,

https://github.com/derekparker/delve/blob/2925c0310a76b54c725e380776e251ce16417fe1/pkg/proc/native/proc_linux.go#L52-L55

which it reports with the generic error

https://github.com/derekparker/delve/blob/2925c0310a76b54c725e380776e251ce16417fe1/cmd/dlv/cmds/commands.go#L528-L532

The name testing is a Go internal package name (in $GOROOT/src/testing) and when go build is called (through dlv debug) with that explicit name it interprets it as its own package and generates it without execussion permissions (not sure why, may be related to the mode used).

When using the sub-folder name testing/subfolder Go knows it's not its own package but another one residing inside $GOPATH and it does give it execution permission. The same can be achieved with dlv debug . (to explicitly indicate to use the CWD) or changing the package name from the generic testing to testing-delve (without needing a sub-package).

This can also be checked directly with the go build command:

mkdir -p $GOPATH/src/testing
cd $GOPATH/src/testing
# Empty directory.
go build -o debug testing
# It doesn't fail, it's building the one from `$GOROOT`.
ls -lah debug
# -rw-rw-r-- [...]
dlv exec ./debug
# ./debug is not executable

# Create a `testing` package here
cat <<EOF > hello.go
package main

import "fmt"

func main() {
    fmt.Println("hello")
}
EOF

# Build without using the `testing` name but an explicit reference to the CWD
go build -o debug .
ls -lah debug
# -rwxrwxr-x [...]
dlv exec ./debug
# Type 'help' for list of commands.
# (dlv)

Thanks @schomatis for the detailed answer, I totally forgot about testing being an internal package.
Now I feel all silly for logging this issue.
I tested after renaming the testing folder to something else, and indeed all works as expected.
Sorry for the trouble.

No problem, I actually learned a lot researching this issue :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

aybabtme picture aybabtme  路  3Comments

delaneyj picture delaneyj  路  4Comments

wusendong picture wusendong  路  5Comments

primalmotion picture primalmotion  路  3Comments

luminacious picture luminacious  路  5Comments