Tests failing on 32-bit builds due to unaligned struct in dependency
hairyhenderson opened this issue · 5 comments
This is blocking the Alpine updates (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/67862) because the tests are failing on 32-bit builds (armhf, armv7, x86). I've been able to reproduce locally in a container (docker run --platform=linux/armhf ...
)
The issue seems to be that the keyvalue.Blob
type is misaligned:
type Bytes struct {
bytes []byte
length int64
mu *sync.Mutex
}
I think it should be:
type Bytes struct {
bytes []byte
length int64
mu *sync.Mutex
}
(at least that's what fieldalignment
likes).
I'll fix this in a fork.
Here's the panic:
panic: unaligned 64-bit atomic operation [recovered]
panic: unaligned 64-bit atomic operation
goroutine 44 [running]:
testing.tRunner.func1.2({0x1d34028, 0x292dba8})
/usr/local/go/src/testing/testing.go:1631 +0x274
testing.tRunner.func1()
/usr/local/go/src/testing/testing.go:1634 +0x3fc
panic({0x1d34028, 0x292dba8})
/usr/local/go/src/runtime/panic.go:770 +0xfc
runtime/internal/atomic.panicUnaligned()
/usr/local/go/src/runtime/internal/atomic/unaligned.go:8 +0x24
runtime/internal/atomic.Load64(0x405da1c)
/usr/local/go/src/runtime/internal/atomic/atomic_arm.s:291 +0x14
github.com/hack-pad/hackpadfs/keyvalue/blob.(*Bytes).Len(0x405da10)
/go/pkg/mod/github.com/hack-pad/hackpadfs@v0.2.1/keyvalue/blob/bytes.go:56 +0x24
github.com/hack-pad/hackpadfs/keyvalue.(*runOnceFileRecord).Size(0x405a758)
/go/pkg/mod/github.com/hack-pad/hackpadfs@v0.2.1/keyvalue/record.go:159 +0xa8
github.com/hack-pad/hackpadfs/keyvalue.(*file).Truncate(0x4139070, 0x0)
/go/pkg/mod/github.com/hack-pad/hackpadfs@v0.2.1/keyvalue/file.go:305 +0xf4
github.com/hack-pad/hackpadfs.TruncateFile({0x29464f0, 0x4139070}, 0x0)
/go/pkg/mod/github.com/hack-pad/hackpadfs@v0.2.1/file.go:227 +0x160
github.com/hack-pad/hackpadfs/keyvalue.(*FS).OpenFile(0x3cb23d8, {0x41a6411, 0x7}, 0x242, 0x1a4)
/go/pkg/mod/github.com/hack-pad/hackpadfs@v0.2.1/keyvalue/fs.go:231 +0x5a4
github.com/hack-pad/hackpadfs/mem.(*FS).OpenFile(0x3cb2418, {0x41a6411, 0x7}, 0x242, 0x1a4)
/go/pkg/mod/github.com/hack-pad/hackpadfs@v0.2.1/mem/fs.go:29 +0x40
github.com/hack-pad/hackpadfs.OpenFile({0x2930120, 0x3cb2418}, {0x41a6411, 0x7}, 0x242, 0x1a4)
/go/pkg/mod/github.com/hack-pad/hackpadfs@v0.2.1/fs.go:158 +0x234
github.com/hairyhenderson/gomplate/v4/internal/datafs.(*wdFS).OpenFile(0x4138f60, {0x2191650, 0x8}, 0x242, 0x1a4)
/go/src/github.com/hairyhenderson/gomplate/internal/datafs/wdfs.go:382 +0x140
github.com/hack-pad/hackpadfs.OpenFile({0x2930944, 0x4138f60}, {0x2191650, 0x8}, 0x242, 0x1a4)
/go/pkg/mod/github.com/hack-pad/hackpadfs@v0.2.1/fs.go:158 +0x234
github.com/hairyhenderson/gomplate/v4.createOutFile.func1()
/go/src/github.com/hairyhenderson/gomplate/template.go:323 +0x154
github.com/hairyhenderson/gomplate/v4/internal/iohelpers.(*lazyWriteCloser).openWriter.func1()
/go/src/github.com/hairyhenderson/gomplate/internal/iohelpers/writers.go:205 +0x24
sync.(*Once).doSlow(0x437c594, 0x416dec8)
/usr/local/go/src/sync/once.go:74 +0xc8
sync.(*Once).Do(0x437c594, 0x416dec8)
/usr/local/go/src/sync/once.go:65 +0x40
github.com/hairyhenderson/gomplate/v4/internal/iohelpers.(*lazyWriteCloser).openWriter(0x437c580)
/go/src/github.com/hairyhenderson/gomplate/internal/iohelpers/writers.go:204 +0x48
github.com/hairyhenderson/gomplate/v4/internal/iohelpers.(*lazyWriteCloser).Write(0x437c580, {0x41a6370, 0xb, 0xb})
/go/src/github.com/hairyhenderson/gomplate/internal/iohelpers/writers.go:219 +0x1c
github.com/hairyhenderson/gomplate/v4/internal/iohelpers.(*emptySkipper).Write(0x405d980, {0x41a6370, 0xb, 0xb})
/go/src/github.com/hairyhenderson/gomplate/internal/iohelpers/writers.go:62 +0x60
github.com/hairyhenderson/gomplate/v4.TestOpenOutFile(0x4212808)
/go/src/github.com/hairyhenderson/gomplate/template_test.go:34 +0x364
testing.tRunner(0x4212808, 0x2248870)
/usr/local/go/src/testing/testing.go:1689 +0x128
created by testing.(*T).Run in goroutine 1
/usr/local/go/src/testing/testing.go:1742 +0x3c4
Filed hack-pad/hackpadfs#43 about this. I think I have a path forward!
While hackpadfs
is working now, there's another alignment issue somewhere:
datasources_vault_ec2_test.go:106:
Error Trace: /home/hairyhenderson/go/src/github.com/hairyhenderson/gomplate/internal/tests/integration/integration_test.go:63
/home/hairyhenderson/go/src/github.com/hairyhenderson/gomplate/internal/tests/integration/datasources_vault_ec2_test.go:106
Error: Received unexpected error:
renderTemplate: failed to render template <arg>: template: <arg>:1:3: executing "<arg>" at <ds "vault" "foo">: error calling ds: unaligned 64-bit atomic operation
Test: TestDatasources_VaultEc2
The go-fsimpl bug is fixed in hairyhenderson/go-fsimpl#720. Release v0.1.4 has that fix and I'll update to that soon.
One last test failure:
--- FAIL: TestStrings_Repeat (0.00s)
strings_test.go:30: assertion failed: expected error to contain "too long: causes overflow", got "renderTemplate: failed to render template <arg>: template: <arg>:1:12: executing \"<arg>\" at <strings.Repeat>: error calling Repeat: negative count -1"
FAIL
I'm pretty sure this is a problem with the test.