[SOLVED] Crash with (beta) rclone mount after a few days... log included

Sorry I missed that...

2020/08/25 02:21:15 ERROR : file.mkv: R
eadFileHandle.Read error: low level retry 1/10: read tcp [2a01:e0a:352:52d1::40]:60201->[2a00:1450:4007:816::200a]:443: i/o timeout
The service rclone has been stopped.
unexpected fault address 0x23600620020
fatal error: fault
[signal 0xc0000005 code=0x1 addr=0x23600620020 pc=0x83e6a]

goroutine 17 [running, locked to thread]:
runtime.throw(0x171495b, 0x5)
        runtime/panic.go:1116 +0x79 fp=0xc0017418f8 sp=0xc0017418c8 pc=0x4c259
runtime.sigpanic()
        runtime/signal_windows.go:249 +0x24f fp=0xc001741928 sp=0xc0017418f8 pc=0x60f4f
runtime.memmove(0x23600620000, 0x23606150000, 0x1000)
        runtime/memmove_amd64.s:365 +0x42a fp=0xc001741930 sp=0xc001741928 pc=0x83e6a
github.com/rclone/rclone/fs/asyncreader.(*AsyncReader).Read(0xc003338230, 0x23600620000, 0x80000, 0x40000000, 0x0, 0x0, 0x0)
        github.com/rclone/rclone/fs/asyncreader/asyncreader.go:157 +0x1a7 fp=0xc001741980 sp=0xc001741930 pc=0x465007
github.com/rclone/rclone/fs/accounting.(*Account).read(0xc006ec35e0, 0x19ba000, 0xc003338230, 0x23600620000, 0x80000, 0x40000000, 0xc007dac770, 0x0, 0x0)
        github.com/rclone/rclone/fs/accounting/accounting.go:309 +0xae fp=0xc0017419e8 sp=0xc001741980 pc=0x55ce2e
github.com/rclone/rclone/fs/accounting.(*Account).Read(0xc006ec35e0, 0x23600620000, 0x80000, 0x40000000, 0x0, 0x0, 0x0)
        github.com/rclone/rclone/fs/accounting/accounting.go:320 +0xc5 fp=0xc001741a60 sp=0xc0017419e8 pc=0x55cf85
io.ReadAtLeast(0x19b9f80, 0xc006ec35e0, 0x23600620000, 0x80000, 0x40000000, 0x80000, 0x80000, 0x0, 0x0)
        io/io.go:314 +0x8e fp=0xc001741ac0 sp=0xc001741a60 pc=0x9346e
io.ReadFull(...)
        io/io.go:333
github.com/rclone/rclone/vfs.(*ReadFileHandle).readAt(0xc00bc75100, 0x23600620000, 0x80000, 0x40000000, 0x662ff0993, 0x1a096c0, 0xc00bc75100, 0x0)
        github.com/rclone/rclone/vfs/read.go:297 +0x6b9 fp=0xc001741c38 sp=0xc001741ac0 pc=0x1146d79
github.com/rclone/rclone/vfs.(*ReadFileHandle).ReadAt(0xc00bc75100, 0x23600620000, 0x80000, 0x40000000, 0x662ff0993, 0x0, 0x0, 0x0)
        github.com/rclone/rclone/vfs/read.go:212 +0xbc fp=0xc001741ca8 sp=0xc001741c38 pc=0x11461dc
github.com/rclone/rclone/cmd/cmount.(*FS).Read(0xc0001aae80, 0xc00886f9f0, 0x48, 0x23600620000, 0x80000, 0x40000000, 0x662ff0993, 0x7, 0xc001741e80)
        github.com/rclone/rclone/cmd/cmount/fs.go:379 +0x271 fp=0xc001741db0 sp=0xc001741ca8 pc=0x115dc71
github.com/billziss-gh/cgofuse/fuse.hostRead(0x23652e04cb0, 0x23600620000, 0x80000, 0x662ff0993, 0x5befdff790, 0x0)
        github.com/billziss-gh/cgofuse@v1.4.0/fuse/host.go:245 +0x102 fp=0xc001741e30 sp=0xc001741db0 pc=0x1118862
github.com/billziss-gh/cgofuse/fuse.go_hostRead(...)
        github.com/billziss-gh/cgofuse@v1.4.0/fuse/host_cgo.go:880
github.com/billziss-gh/cgofuse/fuse._cgoexpwrap_e4f666a8d790_go_hostRead(0x23652e04cb0, 0x23600620000, 0x80000, 0x662ff0993, 0x5befdff790, 0x7ffd6680b586)
        _cgo_gotypes.go:750 +0x5a fp=0xc001741e70 sp=0xc001741e30 pc=0x111e37a
runtime.call64(0x0, 0x5befdff590, 0x5befdff700, 0x30)
        runtime/asm_amd64.s:541 +0x45 fp=0xc001741ec0 sp=0xc001741e70 pc=0x81285
runtime.cgocallbackg1(0x0)
        runtime/cgocall.go:332 +0x1b8 fp=0xc001741f58 sp=0xc001741ec0 pc=0x151b8
runtime.cgocallbackg(0x0)
        runtime/cgocall.go:207 +0xe5 fp=0xc001741fc0 sp=0xc001741f58 pc=0x14f45
runtime.cgocallback_gofunc(0x0, 0x0, 0x0, 0x0)
        runtime/asm_amd64.s:794 +0xb2 fp=0xc001741fe0 sp=0xc001741fc0 pc=0x82992
runtime.goexit()

The problem appears to be that (*AsyncReader).Read was called with a slice with a mad length pointer: 0xc003338230, length: 0x23600620000, capacity: 0x80000

This magic number is visible in the stack trace all the way back to the call from WinFSP

github.com/billziss-gh/cgofuse/fuse._cgoexpwrap_e4f666a8d790_go_hostRead(0x23652e04cb0, 0x23600620000, 0x80000, 0x662ff0993, 0x5befdff790, 0x7ffd6680b586)
        _cgo_gotypes.go:750 +0x5a fp=0xc001741e70 sp=0xc001741e30 pc=0x111e37a

So it looks like that came from WinFSP itself.

So this might be a WinFSP problem... Or it could be a general problem with your computer like bad RAM.

Thx for the input.

I tested with memtest few months ago, all was allright. I don't have errors since removing nmap, and recently I updated to winfsp 2020 beta 3, maybe I'll use nmap again, and see if it's solved.

If using the --mmap is the problem then that could explain it. I'm interested in your findings.

Did you figure out if it was the --mmap option works?

Also should update to the latest WinFSP again.

Sorry for the delay. I'm using --use-mmap again for 2 weeks now, with the latest beta at the time, and no problem for now.

So, I don't know, since the start of this problem, a lot of windows updates happened, rclone betas, etc.. Sorry if it's pretty inconclusive.

1 Like

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