panic: unaligned 64-bit atomic operation on AWS Fargate X86_64 CPU architecture

[wricardo]

Versions

Sarama	Kafka	Go
1.36.0	3.2.0	1.18

Configuration

I'm using default configurations sarama.NewConfig()

Problem Description

Deploying my consumer to AWS Fargate on X86_64 CPU architecture, causes panic:

panic: unaligned 64-bit atomic operation
goroutine 1 [running]:

runtime/internal/atomic.panicUnaligned()
/usr/local/go/src/runtime/internal/atomic/unaligned.go:8 +0x2d	

runtime/internal/atomic.Load64(0xb6a8b34)
/usr/local/go/src/runtime/internal/atomic/atomic_386.s:225 +0x10

github.com/Shopify/sarama.(*client).tryRefreshMetadata(0xb6a8ae0, {0x0, 0x0, 0x0}, 0x3, {0x0, 0x0, 0x0})
/go/pkg/mod/github.com/!shopify/[email protected]/client.go:916 +0x43f

github.com/Shopify/sarama.(*client).RefreshMetadata(0xb6a8ae0, {0x0, 0x0, 0x0})
/go/pkg/mod/github.com/!shopify/[email protected]/client.go:499 +0x13f

github.com/Shopify/sarama.NewClient({0xb7005e8, 0x1, 0x1}, 0xb57e6c0)
/go/pkg/mod/github.com/!shopify/[email protected]/client.go:174 +0x22b

github.com/Shopify/sarama.NewConsumerGroup({0xb7005e8, 0x1, 0x1}, {0x95f447b, 0x7}, 0xb57e6c0)
/go/pkg/mod/github.com/!shopify/[email protected]/consumer_group.go:98 +0x3d

According to this issue golang/go#41970 the issue might be fixed by changing the order of the field updateMetaDataMs int64 in the client struct defined in the client.go

[wricardo]

I've forked the library to test and this commit mshaeon@32e6e16 fixed the panic issue.

[dnwe]

@wricardo thanks for reporting this. I've applied the fix, but I wasn't able to find a linter that would prevent us from (re-)introducing this problem in the future, as none of the general fieldalignment tools seem to have any special consideration for atomic values

[twmb]

@dnwe I coincidentally went through this same exercise, if you want to steal this chunk of code: twmb/franz-go@b76183a#diff-9a979a1e38ba79e2c75e54c4bf21fe1a2a1b935e1736666565f992e634dadd0fR27-R59

it will ensure 64 bit atomic access is aligned for arm 32 bit, which would prevent this issue here as well