Debugger stops on the wrong line if they share the source image and the same instruction
Open
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
- Put a breakpoint on line 4.
- Start the debugger.
- 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 . .
setBreakpointsrequest and response looks good.breakpointevent says the breakpoint is on line 4.stackTraceresponse 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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