Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breakpoints set but never hit in CLI or VS Code #3350

Closed
dseravalli opened this issue Apr 28, 2023 · 8 comments
Closed

Breakpoints set but never hit in CLI or VS Code #3350

dseravalli opened this issue Apr 28, 2023 · 8 comments

Comments

@dseravalli
Copy link

  1. What version of Delve are you using (dlv version)? 1.20.2
  2. What version of Go are you using? (go version)? 1.19
  3. What operating system and processor architecture are you using? MacOS Ventura 13.3.1, Apple M1 Pro
  4. What did you do?
    Configured Dockerfile, docker-compose, and VSCode launch.json for remote debugging, connect to debugger, set breakpoints, executed code. I also tried using the delve CLI.
  5. What did you expect to see? Breakpoint hit
  6. What did you see instead? Code executes normally.

Dockerfile

FROM golang:1.19-alpine

RUN apk add --no-cache build-base

ADD ./ /app/
WORKDIR /app/

RUN go install github.com/go-delve/delve/cmd/dlv@latest

RUN go mod vendor
RUN GOOS=linux GOARCH=amd64 go build -gcflags "all=-N -l" -o /tmp/app ./app/main/server.go

EXPOSE 8080 
EXPOSE 2345

CMD ["dlv", "exec", "/tmp/app", "--continue", "--accept-multiclient", "--listen=:2345", "--headless", "--api-version=2", "--log"]

docker-compose.yml

version: '3.8'

services:
  api:
    build:
      context: ./api
      dockerfile: Dockerfile.local
    ports:
      - "8080:8080"
      - "2345:2345"
    security_opt:
      - apparmor:unconfined
      - seccomp:unconfined
    cap_add:
      - SYS_PTRACE
    volumes:
      - ./api/:/app

.vscode/launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Docker",
      "type": "go",
      "debugAdapter": "dlv-dap",
      "host": "127.0.0.1",
      "port": 2345,
      "request": "attach",
      "mode": "remote",
      "showLog": true,
      "logOutput": "rpc,dap",
      "trace": "verbose",
      "substitutePath": [
        {
          "from": "${workspaceFolder}/backend/services/api/",
          "to": "/app/"
        }
      ]
    }
  ]
}

relevant logs:

API server listening at: [::]:2345
2023-04-28T22:00:08Z warning layer=rpc Listening for remote connections (connections are not authenticated nor encrypted)
2023-04-28T22:00:08Z info layer=debugger launching process with args: [/tmp/app]
2023-04-28T22:00:08Z warning layer=debugger asyncpreemptoff field unreadable: input/output error
2023-04-28T22:00:08Z debug layer=debugger continuing
2023-04-28T22:00:50Z debug layer=debugger halting
2023-04-28T22:00:50Z error layer=rpc writing response:write tcp 127.0.0.1:2345->127.0.0.1:40758: use of closed network connection
2023-04-28T22:00:50Z info layer=debugger created breakpoint: &api.Breakpoint{ID:3, Name:"sourceBp Path=\"/Users/dseravalli/projectname/backend/services/api/handlers/user.resolvers.go\"  Line=474 Column=0", Addr:0x1789516, Addrs:[]uint64{0x1789516}, AddrPid:[]int{15}, File:"/app/handlers/user.resolvers.go", Line:474, FunctionName:"github.com/dseravalli/projectname/backend/services/api/handlers.(*queryResolver).Me", Cond:"", HitCond:"", HitCondPerG:false, Tracepoint:false, TraceReturn:false, Goroutine:false, Stacktrace:0, Variables:[]string(nil), LoadArgs:(*api.LoadConfig)(nil), LoadLocals:(*api.LoadConfig)(nil), WatchExpr:"", WatchType:0x0, VerboseDescr:[]string(nil), HitCount:map[string]uint64{}, TotalHitCount:0x0, Disabled:false, UserData:interface {}(nil)}
2023-04-28T22:00:50Z debug layer=debugger continuing
@aarzilli
Copy link
Member

Very interesting. It used to be that this setup (running linux/amd64 on M1) would fail loudly: #2910. It seems to have progressed now to the point where it fails silently.
What is your setup with docker exactly? Are you running docker itself under rosetta? Which version of docker? Can you figure out what emulator is it using now under the hood?

@aarzilli
Copy link
Member

@dseravalli
Copy link
Author

dseravalli commented Apr 29, 2023

Are you doing this: https://levelup.gitconnected.com/docker-on-apple-silicon-mac-how-to-run-x86-containers-with-rosetta-2-4a679913a0d5 ?

No I wasn't doing this. Just tested that config and it break things further. I can't reach the HTTP server my app is running. I just get Error: socket hang up. I verified that my app works without delve in the mix. Regarding delve, I'm able to connect in VS Code but when I add breakpoints, VS Code greys them out with "input/output error"

Logs

API server listening at: [::]:2345
2023-04-29T14:57:13Z warning layer=rpc Listening for remote connections (connections are not authenticated nor encrypted)
2023-04-29T14:57:13Z info layer=debugger launching process with args: [/tmp/app]
2023-04-29T14:57:13Z warning layer=debugger asyncpreemptoff field unreadable: input/output error
2023-04-29T14:57:13Z debug layer=debugger continuing
2023-04-29T14:57:20Z debug layer=debugger halting
2023-04-29T14:57:20Z error layer=rpc writing response:write tcp 127.0.0.1:2345->127.0.0.1:54458: use of closed network connection
2023-04-29T14:57:20Z debug layer=debugger continuing
2023-04-29T14:57:25Z debug layer=debugger halting
2023-04-29T14:57:25Z debug layer=debugger continuing (direction congruent)

Versions

docker desktop v4.19.0 (latest)
Engine 23.0.5
Compose v2.17.3

@aarzilli
Copy link
Member

As far as I know what you are trying to do (debugging an amd64 application running inside a container running under arm64) is impossible. It would be interesting, however, to find out what docker changed that made this problem look more subtle.

@ZekeLu
Copy link
Contributor

ZekeLu commented May 16, 2023

@aarzilli It looks like there is a misunderstanding. The docker-compose.yml file does not specify the target platform (see service platform and build platforms). So it should default to the host system (that is "MacOS Ventura 13.3.1, Apple M1 Pro").

The issue does not involve "running an amd64 container on an arm64 host" (#2910). It's running an arm64 container on an arm64 host. So I think the issue here is that @dseravalli tries to debug an amd64 application running inside an arm64 container. This is impossible. I think the fix should be removing GOARCH=amd64 from

RUN GOOS=linux GOARCH=amd64 go build -gcflags "all=-N -l" -o /tmp/app ./app/main/server.go

(if the application can run on arm64).

@dseravalli Can you have a try?

@dseravalli
Copy link
Author

@aarzilli It looks like there is a misunderstanding. The docker-compose.yml file does not specify the target platform (see service platform and build platforms). So it should default to the host system (that is "MacOS Ventura 13.3.1, Apple M1 Pro").

The issue does not involve "running an amd64 container on an arm64 host" (#2910). It's running an arm64 container on an arm64 host. So I think the issue here is that @dseravalli tries to debug an amd64 application running inside an arm64 container. This is impossible. I think the fix should be removing GOARCH=amd64 from

RUN GOOS=linux GOARCH=amd64 go build -gcflags "all=-N -l" -o /tmp/app ./app/main/server.go

(if the application can run on arm64).

@dseravalli Can you have a try?

I had fixed it by changing GOARCH to arm64 but yes removing it entirely works too

@ZekeLu
Copy link
Contributor

ZekeLu commented May 16, 2023

Thanks for confirming! Then I think this issue is a false alarm and can be closed.

@aarzilli
Copy link
Member

Closing, thanks @ZekeLu for noticing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants