docker / docker/buildx

Debugger stops on the wrong line if they share the source image and the same instruction

Open
#3,482 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
4.5k
Forks
682
Avg merge
2d 14h
Merged PRs (30d)
29

Description

github.com/docker/buildx v0.29.1-desktop.1 28f6246ff24e2c05095e8741e48c48dcb2d3b4bc
  1. Put a breakpoint on line 4.
  2. Start the debugger.
  3. It stops on line 2. :(
FROM alpine:3.22 AS source
RUN echo "Hello world"
FROM alpine:3.22
RUN echo "Hello world"
COPY --from=source . .
  1. setBreakpoints request and response looks good.
  2. breakpoint event says the breakpoint is on line 4.
  3. stackTrace response says we're stopped on line 2.
{
    "command": "setBreakpoints",
    "arguments": {
        "source": {
            "name": "Dockerfile",
            "path": "/tmp/buildx-debugging-demo/Dockerfile"
        },
        "lines": [
            4
        ],
        "breakpoints": [
            {
                "line": 4
            }
        ],
        "sourceModified": false
    },
    "type": "request",
    "seq": 3
}
{
    "seq": 4,
    "type": "response",
    "request_seq": 3,
    "success": true,
    "command": "setBreakpoints",
    "body": {
        "breakpoints": [
            {
                "id": 1,
                "verified": false,
                "line": 4,
                "endLine": 4
            }
        ]
    }
}
{
    "seq": 9,
    "type": "event",
    "event": "breakpoint",
    "body": {
        "reason": "changed",
        "breakpoint": {
            "id": 1,
            "verified": true,
            "line": 4,
            "endLine": 4
        }
    }
}
{
    "seq": 10,
    "type": "event",
    "event": "stopped",
    "body": {
        "reason": "breakpoint",
        "description": "Paused on breakpoint",
        "threadId": 1,
        "hitBreakpointIds": [
            1
        ]
    }
}
{
    "command": "threads",
    "type": "request",
    "seq": 6
}
{
    "seq": 11,
    "type": "response",
    "request_seq": 6,
    "success": true,
    "command": "threads",
    "body": {
        "threads": [
            {
                "id": 1,
                "name": "default"
            }
        ]
    }
}
{
    "command": "stackTrace",
    "arguments": {
        "threadId": 1,
        "startFrame": 0,
        "levels": 20
    },
    "type": "request",
    "seq": 7
}
{
    "seq": 12,
    "type": "response",
    "request_seq": 7,
    "success": true,
    "command": "stackTrace",
    "body": {
        "stackFrames": [
            {
                "id": 3,
                "name": "[source 2/2] RUN echo \"Hello world\"",
                "source": {
                    "name": "Dockerfile",
                    "path": "/tmp/buildx-debugging-demo/Dockerfile"
                },
                "line": 2,
                "column": 0,
                "endLine": 2
            }
        ]
    }
}

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the report with the shown Dockerfile and buildx v0.29.1-desktop.1. Compare the setBreakpoints response and breakpoint event with the later stackTrace response, focusing on why the hit breakpoint is line 4 while the stack frame reports line 2. Done means the stack trace identifies the same source line as the verified breakpoint.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker
Domain
cli, devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.