你使用的Go版本是什么( go version )?
go version go1.14.2 linux/arm
这个问题在最新版本中是否会重现？
是的。
你正在使用什么操作系统和处理器架构( go env )?
GO111MODULE=""
GOARCH="arm"
GOBIN=""
GOCACHE="/home/pi/.cache/go-build"
GOENV="/home/pi/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/usr/local/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_arm"
GCCGO="gccgo"
GOARM="7"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/pi/azure-storage-azcopy-10.3.4/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build366671593=/tmp/go-build -gno-record-gcc-switches"你做了什么？
编译并使用了azcopy。azcopy有时会发生段错误。打开了一个问题( Azure/azure-storage-azcopy#882 ) ,开发者建议这是一个与ARM上的golang相关的问题。
wget https://github.com/Azure/azure-storage-azcopy/archive/10.3.4.zip
tar zxvf 10.3.4.zip
cd azure-storage-azcopy-10.3.4/
go build
go install你期望看到什么？
完成上传。
你实际看到了什么？
pi@pbsorca:~ $ azure-storage-azcopy copy --recursive "$RAWFS" "$RAWFS_SAS" --log-level warning
INFO: Scanning...
Job 768e77f4-9f04-ee48-7fa4-b287ee176e20 has started
Log file is located at: /home/pi/.azcopy/768e77f4-9f04-ee48-7fa4-b287ee176e20.log
0.0 %, 0 Done, 0 Failed, 10000 Pending, 0 Skipped, 10000 Total (scanning...), unexpected fault address 0x0
fatal error: fault
[signal SIGBUS: bus error code=0x1 addr=0x0 pc=0x1296c]
goroutine 164 [running]:
runtime.throw(0x60c151, 0x5)
/usr/local/go/src/runtime/panic.go:1116 +0x5c fp=0x539b8fc sp=0x539b8e8 pc=0x460f0
runtime.sigpanic()
...请查看附件以获取完整的跟踪信息。
azcopy-golang-seg.txt
5条答案
按热度按时间avkwfej41#
请查看原始问题，您是否能够证明/反驳对齐是否是一个问题？从原始线程中看不清楚，似乎可以通过检查https://github.com/Azure/azure-storage-azcopy/blob/master/common/atomicmorph.go#L16附近的对齐来轻松测试。此外，您是否有一个更小的复现案例？
bd1hkmkf2#
我确实尝试过他们的分支进行对齐，但没有解决问题。不幸的是，我没有一个很好的复现案例。AzCopy在某些文件夹上可以正常工作，而在其他文件夹上则不能。我可以尝试找出一些始终会失败的文件。
t3irkdon3#
这个文件(附加的)似乎失败了(不需要解压).请注意，如果你已经解压了，里面的FLAC也无法上传.
Windows：
$x_{1c0d1}x$
Pi/ARM:
$x_{1a0b}1x$
$x_{1e0f}1x$
lnlaulya4#
我强烈怀疑对齐问题。
底层结构的地址计算如下：
我不明白为什么
CommandStringLength会是4的倍数。它被初始化为
所以我认为
JobPartPlanTransfer并没有在正确对齐的位置写入文件。你应该能够轻松地检查这一点。在每次赋值和使用时添加一个Assert，确保
CommandStringLength是4的倍数。hi3rlvi25#
感谢@randall77。我们(AzCopy团队)将对此进行调查。