runtime: 1.22 breaks code that worked with 1.21 #65706
Comments
|
Further info: I ran I did a
I think it would not be impossible for this to be a case where we accidentally relied on some weird undocumented behaviour or something, but I can't fathom what it could be. |
markus-wa
changed the title
gopherbot
added
the
compiler/runtime
mauri870
added
the
NeedsInvestigation
|
@markus-wa thank you for this report! Could you please try to isolate a standalone reproduction that can massively help in crafting the fix and tests and trivially runnable by anyone? |
|
I appreciate the request @odeke-em, but right now I don't really know where to start. I reckon the failing test is just a symptom of something much deeper, and the issue likely lies far away from any of the panic's stack-trace. If I can find some time, I will investigate this further, but I can't say how quickly I'll be able to produce a practical minimal reproduction example as it's tough to isolate some of the code in the linked repo. |
seankhliao
added
the
WaitingForInfo
|
Even just the appropriate line numbers or the full failing stack trace can help out. Your report doesn't show the line numbers. When I try your reproduction instructions I don't get the same problem, I get back the following $ go version && go test -run TestS2 ./pkg/demoinfocs
go version go1.22.0 darwin/amd64
--- FAIL: TestS2 (0.00s)
demoinfocs_test.go:210:
Error Trace: /Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/pkg/demoinfocs/demoinfocs_test.go:210
Error: Received unexpected error:
open ../../test/cs-demos/s2/s2.dem: no such file or directory
Test: TestS2
Messages: error opening demo "../../test/cs-demos/s2/s2.dem"
demoinfocs_test.go:679:
Error Trace: /Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/pkg/demoinfocs/demoinfocs_test.go:679
/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/pkg/demoinfocs/demoinfocs_test.go:674
/Users/emmanuelodeke/go/src/go.googlesource.com/go/src/runtime/panic.go:770
/Users/emmanuelodeke/go/pkg/mod/github.com/markus-wa/gobitread@v0.2.3/bitread.go:86
/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/internal/bitread/bitread.go:142
/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/internal/bitread/bitread.go:162
/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/pkg/demoinfocs/parser.go:380
/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/pkg/demoinfocs/demoinfocs_test.go:217
Error: Received unexpected error:
invalid argument
Test: TestS2
Messages: failed to close file, reader or writer
panic: invalid argument [recovered]
panic: invalid argument
goroutine 21 [running]:
testing.tRunner.func1.2({0x6497640, 0x6ad6a60})
/Users/emmanuelodeke/go/src/go.googlesource.com/go/src/testing/testing.go:1631 +0x24a
testing.tRunner.func1()
/Users/emmanuelodeke/go/src/go.googlesource.com/go/src/testing/testing.go:1634 +0x377
panic({0x6497640?, 0x6ad6a60?})
/Users/emmanuelodeke/go/src/go.googlesource.com/go/src/runtime/panic.go:770 +0x132
github.com/markus-wa/gobitread.(*BitReader).OpenWithBuffer(0xc000323ce0, {0x65bd638?, 0x0?}, {0xc000380000?, 0x20000?, 0x645f2c0?})
/Users/emmanuelodeke/go/pkg/mod/github.com/markus-wa/gobitread@v0.2.3/bitread.go:86 +0xc5
github.com/markus-wa/demoinfocs-golang/v4/internal/bitread.newBitReader({0x65bd638, 0x0}, 0xc000126510)
/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/internal/bitread/bitread.go:142 +0x86
github.com/markus-wa/demoinfocs-golang/v4/internal/bitread.NewLargeBitReader(...)
/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/internal/bitread/bitread.go:162
github.com/markus-wa/demoinfocs-golang/v4/pkg/demoinfocs.NewParserWithConfig({0x65bd638, 0x0}, {0x0, 0x0, 0x0, {0x0, 0x0, 0x0}, 0x0, {0x0, ...}})
/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/pkg/demoinfocs/parser.go:380 +0xae
github.com/markus-wa/demoinfocs-golang/v4/pkg/demoinfocs_test.TestS2(0xc00013d1e0)
/Users/emmanuelodeke/Desktop/openSrc/bugs/golang/65706/demoinfocs-golang/pkg/demoinfocs/demoinfocs_test.go:217 +0x23f
testing.tRunner(0xc00013d1e0, 0x65b9238)
/Users/emmanuelodeke/go/src/go.googlesource.com/go/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
/Users/emmanuelodeke/go/src/go.googlesource.com/go/src/testing/testing.go:1742 +0x390
FAIL github.com/markus-wa/demoinfocs-golang/v4/pkg/demoinfocs 1.173s
FAIL |
|
Right, sorry about that - I forgot that the required testdata isn't downloaded by default as it's quite big. Just edited the bug description. You'll need to first run This failing CI job has the full error as well: https://github.com/markus-wa/demoinfocs-golang/actions/runs/7900058618/job/21560795144?pr=508 Here is the full stack trace: |
seankhliao
added
WaitingForInfo
|
@markus-wa Did your program work with 1.20? It has the same growth factors as 1.22. Does your program pass the race detector? I could see an undiagnosed race being triggered by a different map growth schedule. |
|
Very interesting! Downgrading to 1.20 does indeed break it as well! The test does pass the race detector, however - and in general it's not just the test that's affected, the whole library always works on 1.21 using vast datasets that would probably lead to different map growth scheduling characteristics (if that makes sense - that's just me guessing really) So I wonder in what kind of other situation such a change could break/"fix" code? What would be the best steps to figuring out why these two load factors behave differently? PS: I suppose this could be hinting at the idea that actually go1.21 was bugged, which we somehow relied upon in a weird way. if that would be the case I guess that would probably warrant a backport of the fix to 1.21 once we figure out why the different behaviour occurrs |
Your thought is correct. It is not possible for this change to break spec-compliant programs. I would audit all the uses of Just plain debugging your program would be a good step as well. Where is that |
|
The map ordering thought is interesting - I'll take a look. I'm not sure about Anyway, I'll report back after some more investigation! |
|
I'm not exactly sure where the behaviour came from but changing some seemingly non-map-related logic fixed the issue. I would love to figure out what exactly happened here as I still don't think my program wasn't spec compliant but for lack of time and understanding of the matter I think I'll close this issue for now. |
Go version
go1.22.0
Output of
go envin your module/workspace:What did you do?
Upgrade from
go1.21.7togo1.22.0and thenSee also failing CI job with
go1.22.0: https://github.com/markus-wa/demoinfocs-golang/actions/runs/7900058618/job/21560795144?pr=508What did you see happen?
Test fails with
interface conversion: interface {} is *sendtables2.fieldState, not uint64- I think this is just a side-effect of another issue.Full stack trace:
What did you expect to see?
Test passes, as it did with
go1.21.7The text was updated successfully, but these errors were encountered: