Hi,
I’m basically looking for an idea where to start looking for the bug…
I’m cross-compiling the following Azure application for managing Azure storage from Windows for using it on a Raspberry Pi in 32-bit mode under Debian Linux:
The environment variables for go build were set as follows:
$env:GOOS = "linux"
$env:GOARCH = "arm"
$env:GOARM= "5"
The resulting program can be executed in general on the Raspberry Pi, e.g. I can invoke it to get the usage message:
stm@raspberrypi:~$ ./azure-storage-azcopy -h
AzCopy 10.16.2
Project URL: github.com/Azure/azure-storage-azcopy
...
But when I attempt an actual operation it crashes:
stm@raspberrypi:~$ ./azure-storage-azcopy list https://some.blob.core.windows.net/videobackup
INFO: Authenticating to source using Azure AD
SIGILL: illegal instruction
PC=0x133ec m=5 sigcode=4
instruction bytes: 0x38 0x60 0x9f 0xe5 0x6 0x0 0x50 0xe1 0x6 0x0 0x0 0x9a 0x0 0x10 0xe0 0xe3
goroutine 1 [syscall]:
syscall.Syscall6(0x900137, 0x0, 0xfffffffd, 0x1, 0x0, 0x0, 0x0)
C:/Program Files/Go/src/syscall/syscall_linux.go:90 +0x8 fp=0x1a8f7a8 sp=0x1a8f770 pc=0xd7264
github.com/wastore/keyctl.keyctl(0x0, {0x1a8f818, 0x2, 0x2})
C:/Users/stm/go/pkg/mod/github.com/wastore/keyctl@v0.3.1/sys_linux.go:114 +0x158 fp=0x1a8f7f0 sp=0x1a8f7a8 pc=0x41e7a4
github.com/wastore/keyctl.newKeyring(0xfffffffd)
C:/Users/stm/go/pkg/mod/github.com/wastore/keyctl@v0.3.1/sys_linux.go:194 +0x4c fp=0x1a8f820 sp=0x1a8f7f0 pc=0x41ed4c
github.com/wastore/keyctl.SessionKeyring(...)
C:/Users/stm/go/pkg/mod/github.com/wastore/keyctl@v0.3.1/keyring.go:68
github.com/Azure/azure-storage-azcopy/v10/common.(*CredCache).hasCachedTokenInternal(0x151e3c0)
E:/Users/stm/Documents/GitHub/azure-storage-azcopy/common/credCache_linux.go:112 +0x1c fp=0x1a8f83c sp=0x1a8f820 pc=0x76f738
github.com/Azure/azure-storage-azcopy/v10/common.(*CredCache).HasCachedToken(0x151e3c0)
E:/Users/stm/Documents/GitHub/azure-storage-azcopy/common/credCache_linux.go:69 +0x34 fp=0x1a8f860 sp=0x1a8f83c pc=0x76f560
github.com/Azure/azure-storage-azcopy/v10/common.(*UserOAuthTokenManager).getCachedTokenInfo(0x17ffa70, {0xbb2770, 0x151f7a0})
E:/Users/stm/Documents/GitHub/azure-storage-azcopy/common/oauthTokenManager.go:513 +0x24 fp=0x1a8f9a4 sp=0x1a8f860 pc=0x783100
github.com/Azure/azure-storage-azcopy/v10/common.(*UserOAuthTokenManager).GetTokenInfo(0x17ffa70, {0xbb2770, 0x151f7a0})
E:/Users/stm/Documents/GitHub/azure-storage-azcopy/common/oauthTokenManager.go:129 +0xd4 fp=0x1a8fad0 sp=0x1a8f9a4 pc=0x780ee4
github.com/Azure/azure-storage-azcopy/v10/cmd.GetCredentialInfoForLocation({0xbb2770, 0x151f7a0}, 0x3, {0x152eb40, 0x2e}, {0x0, 0x0}, 0x1, {0x0, {0x0, ...}, ...})
... <long stackdump for multiple threads> ...
I would like to understand the reason for the illegal instruction signal:
SIGILL: illegal instruction
PC=0x133ec m=5 sigcode=4
instruction bytes: 0x38 0x60 0x9f 0xe5 0x6 0x0 0x50 0xe1 0x6 0x0 0x0 0x9a 0x0 0x10 0xe0 0xe3
When I disassemble the binary with arm-linux-gnueabihf-objdump -d azure-storage-azcopy then I see the following around the problematic address 0x133ec:
000133cc <runtime/internal/syscall.Syscall6>:
133cc: e59d7004 ldr r7, [sp, #4]
133d0: e59d0008 ldr r0, [sp, #8]
133d4: e59d100c ldr r1, [sp, #12]
133d8: e59d2010 ldr r2, [sp, #16]
133dc: e59d3014 ldr r3, [sp, #20]
133e0: e59d4018 ldr r4, [sp, #24]
133e4: e59d501c ldr r5, [sp, #28]
133e8: ef000000 svc 0x00000000
133ec: e59f6038 ldr r6, [pc, #56] ; 1342c <runtime/internal/syscall.Syscall6+0x60>
133f0: e1500006 cmp r0, r6
133f4: 9a000006 bls 13414 <runtime/internal/syscall.Syscall6+0x48>
I’m not very fluent in ARM assembler, but this looks like valid code, and the byte sequence 0x38 0x60 0x9f 0xe5 does appear at address 133ec: in the assembler listing.
As this application is released by the project itself for other architectures and apparently is working without problem there, I wonder what I’m looking at. Can this be miscompilation, or does this look like a bug in the application or a library?
Stephan