-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
fix: fix field alignment to avoid panics on 32bit OSes #44
fix: fix field alignment to avoid panics on 32bit OSes #44
Conversation
1704878
to
f8a5687
Compare
Signed-off-by: Dave Henderson <[email protected]>
f8a5687
to
eb37578
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not very experienced with these kinds of alignment issues, so I'm definitely open to a bit of discussion on how to handle these.
If at all possible, my strong preference is to maintain field ordering in the table driven test case types to keep it easier to quickly read and understand the tests. Of course if the tests fail, we'll need to do something else 🤔
I can revert the test files, no big deal. |
Signed-off-by: Dave Henderson <[email protected]>
67918d1
to
e6c6709
Compare
Signed-off-by: Dave Henderson <[email protected]>
Signed-off-by: Dave Henderson <[email protected]>
2f03e1c
to
db06695
Compare
Signed-off-by: Dave Henderson <[email protected]>
db06695
to
724f886
Compare
Signed-off-by: Dave Henderson <[email protected]>
51e9ea1
to
0deb83d
Compare
Signed-off-by: Dave Henderson <[email protected]>
0deb83d
to
3c2bd7f
Compare
@JohnStarich thanks for the feedback, I think I've addressed it all - please have another look! (I'm not sure why coveralls thinks the coverage decreased - I added new tests... ¯\_(ツ)_/¯) |
- platform: macos-latest | ||
goarch: '386' | ||
- platform: windows-latest | ||
goarch: '386' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, thanks!
We may want to reduce the matrix a bit to a single 32 bit runner in the future, assuming we can prove the effective coverage is the same. As someone who's worked with 32 bit arch's more than me, do you foresee any problems with only validating those arch's on a single platform and Go version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only reason I didn't also add 32-bit ARM as well is that it's a huge pain to do (without Docker) in GitHub Actions, because the GitHub-hosted runners are all AMD64 currently (ARM64 is coming this fall maybe?).
Another option is to use a self-hosted runner, and I happen to be deep in that rabbit-hole right now (hairyhenderson/gomplate#2126) and it's going about as well as you'd expect (i.e. not at all well).
For this particular class of bug any 32-bit platform will generally do, but there are other classes of bugs that can crop up only on 32-bit ARM CPUs. Somewhat ironically it's extremely rare to run into 32-bit Intel systems except for niche embedded use-cases, but it's still quite common to run into 32-bit ARM given the massive proliferation of older Raspberry Pi-type systems and routers strewn across the IoT landscape.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again! Super appreciate the thought and time you put into this.
I did have one question about the future of maintaining 32 bit support here, since I'm not as well versed in field alignment issues like this. #44 (comment)
TEST_ARGS=-race | ||
# the race detector needs cgo (at least on Linux and Windows, and macOS until Go 1.20) | ||
export CGO_ENABLED=1 | ||
endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, bummer about race not being supported, this looks like a reasonable setup. Thank you for handling all of that. This must've been a pain wrangling with CI for so long.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was already in the midst doing a similar thing for gomplate so it at least wasn't a new kind of pain 😅
It probably isn't always true, but races tend to happen in the same way on all platforms, so I wouldn't be too worried here.
@@ -653,6 +654,7 @@ func TestFileSync(tb testing.TB, o FSOptions) { | |||
assert.NoError(tb, file.Close()) | |||
} | |||
|
|||
//nolint:govet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: This might be doable with a .golangci.yml config change. Will look into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's at least awkward in the golangci config, if not impossible - it lets you disable whole linters (i.e. govet
in this case), but not sub-linters like fieldalignment
.
If you want to avoid linting all tests with govet
, then that's an option, but...
@@ -2,6 +2,7 @@ BROWSERTEST_VERSION = v0.7 | |||
LINT_VERSION = 1.50.1 | |||
GO_BIN = $(shell printf '%s/bin' "$$(go env GOPATH)") | |||
SHELL = bash | |||
ENABLE_RACE = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: Looks like this var is now unused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦♂️ good catch - that can be deleted
Fixes #43
To solve this, I:
fieldalignment
linter (which is a sub-linter ofgovet
)fieldalignment -fix
command to fix misaligned structs that were non-obviousint64
+atomic.StoreInt64
to usingatomic.Int64
(etc) and because of this...keyvalue/blob.Bytes
, which was what was giving me trouble initially