Duplicacy 3.2.2 - crashes on arm 32 bit

Bug
#1

Running the latest 3.2.2 CLI on a Synology arm platform gives the following error - 3.1.0 runs fine.

unaligned 64-bit atomic operation
goroutine 61 [running]:
runtime/debug.Stack()
	/usr/local/go/src/runtime/debug/stack.go:24 +0x78
runtime/debug.PrintStack()
	/usr/local/go/src/runtime/debug/stack.go:16 +0x14
github.com/gilbertchen/duplicacy/src.CatchLogException()
	/Users/gchen/zincbox/duplicacy/src/duplicacy_log.go:233 +0xe8
panic({0xc2a760, 0xfbd5f0})
	/usr/local/go/src/runtime/panic.go:884 +0x23c
runtime/internal/atomic.panicUnaligned()
	/usr/local/go/src/runtime/internal/atomic/unaligned.go:8 +0x24
runtime/internal/atomic.Load64(0x298621c)
	/usr/local/go/src/runtime/internal/atomic/atomic_arm.s:280 +0x14
storj.io/uplink/private/storage/streams/buffer.(*MemoryBackend).Write(0x2986210, {0x281a000, 0x1000, 0x1d00})
	/Users/gchen/zincbox/go/pkg/mod/storj.io/uplink@v1.12.0/private/storage/streams/buffer/backend.go:38 +0x30
storj.io/uplink/private/storage/streams/buffer.(*Buffer).Write(0x2c72b20, {0x281a000, 0x1d00, 0x1d00})
	/Users/gchen/zincbox/go/pkg/mod/storj.io/uplink@v1.12.0/private/storage/streams/buffer/buffer.go:63 +0x144
storj.io/common/encryption.(*transformedWriter).Write(0x2a7e820, {0x28bb000, 0x7000, 0x7000})
	/Users/gchen/zincbox/go/pkg/mod/storj.io/common@v0.0.0-20230907123639-5fd0608fd947/encryption/transform.go:237 +0x280
storj.io/uplink/private/storage/streams/splitter.(*encryptedBuffer).Write(0x2c72b40, {0x28bb000, 0x7000, 0x7000})
	/Users/gchen/zincbox/go/pkg/mod/storj.io/uplink@v1.12.0/private/storage/streams/splitter/encrypted_buffer.go:37 +0xb0
storj.io/uplink/private/storage/streams/splitter.(*baseSplitter).Write(0x2a93b90, {0x28ba000, 0x8000, 0x8000})
	/Users/gchen/zincbox/go/pkg/mod/storj.io/uplink@v1.12.0/private/storage/streams/splitter/base_splitter.go:96 +0x2d4
storj.io/uplink/private/storage/streams/splitter.(*Splitter).Write(...)
	/Users/gchen/zincbox/go/pkg/mod/storj.io/uplink@v1.12.0/private/storage/streams/splitter/splitter.go:120
storj.io/uplink/private/storage/streams.(*Upload).Write(0x2964150, {0x28ba000, 0x8000, 0x8000})
	/Users/gchen/zincbox/go/pkg/mod/storj.io/uplink@v1.12.0/private/storage/streams/upload.go:41 +0xac
storj.io/uplink.(*Upload).Write(0x28d8180, {0x28ba000, 0x8000, 0x8000})
	/Users/gchen/zincbox/go/pkg/mod/storj.io/uplink@v1.12.0/upload.go:168 +0x5c
io.copyBuffer({0xfc02c0, 0x28d8180}, {0xfbeb50, 0x2964180}, {0x0, 0x0, 0x0})
	/usr/local/go/src/io/io.go:429 +0x264
io.Copy(...)
	/usr/local/go/src/io/io.go:386
github.com/gilbertchen/duplicacy/src.(*StorjStorage).UploadFile(0x2bcb680, 0x0, {0x2ac6500, 0x48}, {0x9ed8000, 0xc7f51, 0x1ce000})
	/Users/gchen/zincbox/duplicacy/src/duplicacy_storjstorage.go:157 +0x1b8
github.com/gilbertchen/duplicacy/src.(*ChunkOperator).UploadChunk(0x2a92770, 0x0, {0x1, {0x2be4dc0, 0x40}, {0x281d440, 0x20}, 0x0, {0x0, 0x0}, ...})
	/Users/gchen/zincbox/duplicacy/src/duplicacy_chunkoperator.go:567 +0x5b4
github.com/gilbertchen/duplicacy/src.(*ChunkOperator).Run(0x2a92770, 0x0, {0x1, {0x2be4dc0, 0x40}, {0x281d440, 0x20}, 0x0, {0x0, 0x0}, ...})
	/Users/gchen/zincbox/duplicacy/src/duplicacy_chunkoperator.go:187 +0x1024
github.com/gilbertchen/duplicacy/src.CreateChunkOperator.func1(0x0)
	/Users/gchen/zincbox/duplicacy/src/duplicacy_chunkoperator.go:92 +0x6c
created by github.com/gilbertchen/duplicacy/src.CreateChunkOperator
	/Users/gchen/zincbox/duplicacy/src/duplicacy_chunkoperator.go:87 +0x224
Incomplete snapshot saved to /volume1/Clochettes/duplicacy/.duplicacy/cache/storj/incomplete_snapshot
#2

Is this on a 32 bit system? This may be relevant:

// 64-bit atomic operations require 64-bit alignment, but 32-bit
// compilers do not ensure it.

Solution could be to use atomic.AlignedInt64 instead of int64 whenever possible, or figure out if there are compiler flags to enforce 64 bit alignment

#3

Yes it is, should have made it clearer but thought writing arm and not arm64 would be enough.

I went straight from 3.1.0 to 3.2.2 but will see which version after 3.1.0 it starts to fail with this error later this evening and post the result.

#4

well, most arm devices today are 64 bit… :slight_smile:

Don’t spend time on this, it does not matter which version works and which does not. Fundamentally, there is unaligned data, and if it accidentally happens that in few builds it got aligned correctly it means nothing. One build that exposes the issue is enough. There shall be alignment enforcement in the code – otherwise it could have worked accidentally, or because compiler defaults were different…

#5

It’s a friend’s old Synology. Trying to help them with some data security, at some point, their HDDs will grind to a halt…

It “appears” to begin from 3.2.1. That’s tied to the go version upgrade, I suspect that’s surfaced the underlying issue.

#6

Oh yes, most definitely. Stuff got reshuffled, packed more efficiently, and crossed alignment boundaries.

I’m wondering why did not go linter find that issue.

#7

I believe this is an issue in storj.io/uplink, which was upgraded from v1.9.0 to v1.12.0 for CLI 3.2.1: Update go version to 1.19.13 · gilbertchen/duplicacy@7cc1b42 · GitHub

This is the line caused the crash:

This is the definition of MemoryBackend:

If they can simply swap buf and len like this then the error will go away:

type MemoryBackend struct {
	len    int64
	buf    []byte
	closed bool
}
2 Likes
#8

I’ve filed a bug for them: Regression: "unaligned 64-bit atomic operation" on 32-bit systems · Issue #156 · storj/uplink · GitHub

2 Likes
#9

Many thanks, that’s appreciated.

For now, I’ll stay with 3.1.0 until the fix is provided.

I saw they’ve already applied a fix, swapping the order of the struct around and adding in a static check for arm32 to avoid such a regression going forward.

@gchen hopefully you’ll be able to integrate a newer version into the CLI and perform a maintenance release when that makes sense.

1 Like
#10

The Storj folks have already released a fix

1 Like
#11

Whoa! 6 hours between bug report and fix release! That’s… magnificent!

#12

Building my own arm32 image and pulling in storj-1.12.1 works perfectly as far as I can tell.

Will wait for the official update.

1 Like
#13

Release 3.2.3 has been uploaded: Release Duplicacy Command Line Version 3.2.3 · gilbertchen/duplicacy · GitHub

2 Likes