-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/compile: fails to compile very long files starting go1.17 #51193
Comments
cc @griesemer for decision. |
Another fix is to ensure that when we saturate the line field, we always use column 1. That way incrementing a position never goes backwards. |
Does this work?
|
CC @thanm because DWARF. |
@randall77 just checked; that patch also fixes the issue. |
Change https://go.dev/cl/385795 mentions this issue: |
@sywhang thanks for the report. Just for my curiosity, what is the advantage of using go-bindata as opposed to Go's "go:embed" feature, e.g. https://pkg.go.dev/embed? |
There is no advantage to using go-bindata over go:embed that we're aware of. |
@thanm there isn't. This existed prior to go:embed feature. |
My apologies for commenting a closed issue, we ran into the error in practice when compiling a large auto-generated file, feasible to make a backport? Thanks. @gopherbot please consider this for backport to 1.17, it's a compiler error. |
Backport issue(s) opened: #52095 (for 1.17). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
@randall77 , do you mind preparing a back-port CL for this/ |
@aclements Done. |
What version of Go are you using (
go version
)?My dev laptop is m1 Mac:
But we also verified this fails on linux/amd64 as well.
Does this issue reproduce with the latest release?
Yes, including the go1.18 beta.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Some teams here at Uber were using go-bindata to embed binaries into Go file, which resulted in a very lengthy file (>1 mil lines of Go).
In Go 1.17 these files started seeing build failures, with the following compiler error:
What did you expect to see?
The file being compiled.
What did you see instead?
The compiler error above.
Additional Details
We dug into the source code and found out that this happens due to an overflow bug in cmd/compile. Specifically, the newly added dwarfgen package does not account for the case where XPos can be non-monotonic increment between two characters due to Lico using only 20 bits to represent the line number:
We are unblocked by changing these files to not do this by using go:embed (or opting to not generate DWARF symbols), but I do feel that 20 bits is a bit too limiting since it's possible for code-generated files to reach this length.
We tried a local fix as suggested in the comment - by changing
lico
touint64
and changing the layout as 10 bits reserved (empty), 42 bits for line, 8 bits for column, 2 for isStmt, 2 for pro/epilogue and verified that the fix works.We're happy to submit this fix but I'm posting an issue here before submitting it to discuss potential alternatives. Thanks!
The text was updated successfully, but these errors were encountered: