Go version

go version go1.21.4 linux/amd64

What operating system and processor architecture are you using (go env)?

GO111MODULE=''
GOARCH='amd64'
GOBIN='/home/pato/local/bin'
GOCACHE='/home/pato/.cache/go-build'
GOENV='/home/pato/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/pato/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/pato/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.4'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/pato/src/tg/seqs/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2782340955=/tmp/go-build -gno-record-gcc-switches'

What did you do?

1. Run test for a simple ring buffer implementation using go test ./... or with VSCode visual debugging and no breakpoint
2. Run test with a breakpoint at a certain line.

The code in question is from an open source library: soypat/seqs#8 (comment). This comment is perhaps a bit confusing, but the TL;DR is if you clone the repo and run the test with go test ./... in that commit hash you'll get a different output than if you run the test with a breakpoint on the println statement (I'm using VSCode default visual debugging with dlv).

I actually tried to replicate it on a computer with same OS, arch, go version and had to change the case a bit, here's the line on which you have to add the breakpoint to see the bug for a different computer (different commit hash than first case above).

Previous investigation

@Jorropo investigated this bug. The conversation is on slack. They arrived on a conclusion there was a compiler bug that occurs in go version devel go1.22-2184a39477 Thu Dec 21 18:36:41 2023 +0000 linux/amd64 , though it is my understanding it is unrelated to this breakpoint bug I am detailing here.

What did you expect to see?

I expected to see same behaviour, same things printed since there is no concurrency at play. Running test with -race yields no race.

What did you see instead?

Values are different, and also variables take on "impossible" values. i.e: There are two int type variables, one variable is assigned the value of the other. On the following statement the variable values differ.

First case

No breakpoint output:

test 10 8 8 0xc000196810
test 0 0 0 0xc000196810
--- FAIL: TestRing (0.00s)
    internal_test.go:72: 0 did not write data correctly: got 8; want 4
    internal_test.go:82: got 0; want 6 (2+4)
FAIL

Breakpoint output:

test 0 0 8 0xc000016840
test 0 0 0 0xc000016840
--- FAIL: TestRing (3.42s)
    internal_test.go:82: got 4; want 6 (2+4)
    internal_test.go:85: got "llo "; want "hell"
FAIL

Second case

No breakpoint output:

0 0 1 1
--- FAIL: TestRing2 (0.00s)
    internal_test.go:67: failed test 2
FAIL

With breakpoint output

0 0 0 1
0 0 0 2
0 0 0 1
2 0 0 1
0 0 0 1
1 0 0 1
0 0 0 1
1 0 0 1
0 0 0 1
... it goes on ...
--- FAIL: TestRing2 (1.83s)
    internal_test.go:106: got 1; want 2 (1+1)
    internal_test.go:109: got "\x94"; want "\x01"
    internal_test.go:96: did not write data correctly: got 3; want 2
    internal_test.go:106: got 5; want 4 (2+2)
FAIL