Uploading via rclone crash

Suspected Bug
1

What is the problem you are having with rclone?

When uploading a file via *arr type software to google drive it seems to crash fuse(winfsp) or rclone not sure which one. Tried on another computer and it works fine to upload.

What is your rclone version (output from rclone version)
rclone v1.55.1

  • os/type: windows
  • os/arch: amd64
  • go/version: go1.16.3
  • go/linking: dynamic
  • go/tags: cmount

Also tried the latest beta versions same crash as in log below. Also updated Winfsp to 1.9.

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Windows 10 x64

Which cloud storage system are you using? (eg Google Drive)

Google Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

mount --vfs-cache-mode writes --fast-list --log-level DEBUG gcrypt: X: --config "C:\rclone\rclone.conf" --log-file C:\rclone\rclone.txt --transfers 20 --multi-thread-streams 20

The rclone config contents with secrets removed.

[gdrive]
type = drive
client_id = [secret]
client_secret = [secret]
scope = drive
root_folder_id = [secret]
token = [secret]

[gcrypt]
type = crypt
remote = gdrive:/crypt
filename_encryption = standard
directory_name_encryption = true
password = [secret]
password2 = [secret]

A log from the command with the -vv flag

unexpected fault address 0xffffffffffffffff
fatal error: fault
[signal 0xc0000005 code=0x0 addr=0xffffffffffffffff pc=0x40350e]

goroutine 147 [running, locked to thread]:
runtime.throw(0x1df5fc3, 0x5)
runtime/panic.go:1117 +0x79 fp=0xc00071dd08 sp=0xc00071dcd8 pc=0x43d859
runtime.sigpanic()
runtime/signal_windows.go:245 +0x2d6 fp=0xc00071dd60 sp=0xc00071dd08 pc=0x453796
indexbytebody(0x2f736569766f4d2f, 0x2d1, 0x470300, 0xc000645800, 0x2d1, 0x0, 0x2f736569766f4d2f, 0x2f736569766f4d2f, 0x2d1, 0xc00071de08, ...)
internal/bytealg/indexbyte_amd64.s:124 +0xce fp=0xc00071dd68 sp=0xc00071dd60 pc=0x40350e
runtime.findnull(0x2f736569766f4d2f, 0xc00071de08)

FULL LOG: What is the problem you are having with rclone?When uploading a file via *ar - Pastebin.com

2

Hmm, not sure exactly what is going on there.

It seems to be something to do with the interface between the Go code and the C FUSE bindings in cgofuse.

The full backtrace is this

unexpected fault address 0xffffffffffffffff
fatal error: fault
[signal 0xc0000005 code=0x0 addr=0xffffffffffffffff pc=0x40350e]
 
goroutine 147 [running, locked to thread]:
runtime.throw(0x1df5fc3, 0x5)
	runtime/panic.go:1117 +0x79 fp=0xc00071dd08 sp=0xc00071dcd8 pc=0x43d859
runtime.sigpanic()
	runtime/signal_windows.go:245 +0x2d6 fp=0xc00071dd60 sp=0xc00071dd08 pc=0x453796
indexbytebody(0x2f736569766f4d2f, 0x2d1, 0x470300, 0xc000645800, 0x2d1, 0x0, 0x2f736569766f4d2f, 0x2f736569766f4d2f, 0x2d1, 0xc00071de08, ...)
	internal/bytealg/indexbyte_amd64.s:124 +0xce fp=0xc00071dd68 sp=0xc00071dd60 pc=0x40350e
runtime.findnull(0x2f736569766f4d2f, 0xc00071de08)
	runtime/string.go:438 +0x87 fp=0xc00071ddc0 sp=0xc00071dd68 pc=0x458d67
runtime.gostring(0x2f736569766f4d2f, 0xc0003dba40, 0xc0000de058)
	runtime/string.go:320 +0x36 fp=0xc00071de18 sp=0xc00071ddc0 pc=0x471a56
github.com/billziss-gh/cgofuse/fuse._Cfunc_GoString(...)
	_cgo_gotypes.go:320
github.com/billziss-gh/cgofuse/fuse.c_GoString(...)
	github.com/billziss-gh/cgofuse@v1.5.0/fuse/host_cgo.go:708
github.com/billziss-gh/cgofuse/fuse.hostRelease(0x2f736569766f4d2f, 0x2ec2fc18, 0x0)
	github.com/billziss-gh/cgofuse@v1.5.0/fuse/host.go:284 +0x94 fp=0xc00071de78 sp=0xc00071de18 pc=0x17293b4
github.com/billziss-gh/cgofuse/fuse.go_hostRelease(...)
	github.com/billziss-gh/cgofuse@v1.5.0/fuse/host_cgo.go:926
_cgoexp_12ef5be0dd8c_go_hostRelease(0x2ec2fb80)
	_cgo_gotypes.go:768 +0x3e fp=0xc00071dea0 sp=0xc00071de78 pc=0x172f8fe
runtime.cgocallbackg1(0x172f8c0, 0x2ec2fb80, 0x0)
	runtime/cgocall.go:292 +0x19a fp=0xc00071df40 sp=0xc00071dea0 pc=0x40517a
runtime.cgocallbackg(0x172f8c0, 0x2ec2fb80, 0x0)
	runtime/cgocall.go:228 +0xfc fp=0xc00071dfb8 sp=0xc00071df40 pc=0x404edc
runtime.cgocallback(0x0, 0x0, 0x0)
	runtime/asm_amd64.s:788 +0xc0 fp=0xc00071dfe0 sp=0xc00071dfb8 pc=0x476180
runtime.goexit()
	runtime/asm_amd64.s:1371 +0x1 fp=0xc00071dfe8 sp=0xc00071dfe0 pc=0x476461

So it seems to be cgofuse trying to unmount the filesystem.

It is possible that this crashed masked the real problem.

The addresses is very fishy, so looks like a use after free problem.

>>> bytes.fromhex("2f736569766f4d2f")
b'/seivoM/'

This is where the crash happened

So it was apparently the kernel attempting to call Release on a file at that point and that dud pointer 0x2f736569766f4d2f was passed in to there, probably from WinFSP.

Can you replicate this problem easily?

Could it be a hardware fault on the computer? Have you tried memtest86?

Are you using the latest version of WinFSP?

3

So this may be a due to a bad memory stick, will take some time to scan the memory remove the stick and test again.

I ran a memtest previously but didn't let it run the whole way through or identify the bad stick, but it did have errors during the scan, I just didn't follow up since all the apps were working correctly except this one.

Thanks for the quick reply and solution.

4

Bad memory will cause lots of things to go wrong in random ways. Kill it with fire! Or at least find it and replace it :slight_smile:

5

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.

6

This turned out to be a bug in WinFSP which should be fixed in the beta - please can you try

And see if you can get it to go wrong again?

Thanks

8

No issues so far, will let you know if anything pops up, thanks!

1 Like
9

Thanks for testing :slight_smile: Much appreciated.