Fatal error: runtime: mcall called on m->g0 stack"

[ricifede]

What is the problem you are having with rclone?

I am using rclone in a windows environment.
The problem I am encountering is that, with random frequency, rclone either does not start or during processing it crashes with the error:

"fatal error: runtime: mcall called on m->g0 stack"

In particular, you can run the command many times and it works. When "fatal error: runtime: mcall called on m->g0 stack" appears, it continues to fail.
Renaming the rclone executable and launching the renamed executable sometimes restarts.

The problem occurs even just requesting the version.

rclone version

The server

• is virtual and has 4 gb of free ram.
• the physical server has an amd milan processor
• the windows antivirus is disabled. In its place the With-Secure 25.1 antivirus is active

I tried to

• add the rclone.exe exclusion both to the windows antivirus and to the with-secure antivirus
• disabile With-Secure antivirus
• change rclone x86 and amd64 architecture
• downgrade rclone to the 1.65.2 and 1.64.2 releases
• set --buffer-size=1G --checkers=4
  but obtaining the same problem.

Run the command 'rclone version' and share the full output of the command.

rclone v1.69.1
- os/version: Microsoft Windows Server 2019 Standard 1809 (64 bit)
- os/kernel: 10.0.17763.7009 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.24.0
- go/linking: static
- go/tags: cmount

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

FTPS

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

rclone version
rclone sync 

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[FTPWXXXXX]
type = ftp
host = XXX
user = XXX
pass = XXX
explicit_tls = true
no_check_certificate = true

A log from the command that you were trying to run with the -vv flag

PS D:\rclone> .\rclone.exe version -vv

fatal error: runtime: mcall called on m->g0 stack

runtime stack:
runtime.throw({0x272f7c8?, 0x190?})
        runtime/panic.go:1096 +0x4d fp=0xc00008bc08 sp=0xc00008bbd8 pc=0x47b1cd
runtime.badmcall(0x140108?)
        runtime/proc.go:550 +0x1f fp=0xc00008bc28 sp=0xc00008bc08 pc=0x447d1f
runtime.badmcall(0x445e39)
        <autogenerated>:1 +0x25 fp=0xc00008bc40 sp=0xc00008bc28 pc=0x4882e5
runtime: g 0: unexpected return pc for runtime.badmcall called from 0xc00008bc58
stack: frame={sp:0xc00008bc28, fp:0xc00008bc40} stack=[0x40d4000,0x42cff00)


goroutine 1 gp=0xc0000021c0 m=nil [runnable, locked to thread]:
syscall.GetStdHandle(0xfffffffffffffff6)
        syscall/zsyscall_windows.go:865 +0xc9 fp=0xc00008bdf8 sp=0xc00008bdf0 pc=0x4a6a69
syscall.getStdHandle(...)
        syscall/syscall_windows.go:541
syscall.init()
        syscall/syscall_windows.go:535 +0x11dc fp=0xc00008be28 sp=0xc00008bdf8 pc=0x49b25c
runtime.doInit1(0x3d78140)
        runtime/proc.go:7350 +0xdd fp=0xc00008bf50 sp=0xc00008be28 pc=0x455fdd
runtime.doInit(...)
        runtime/proc.go:7317
runtime.main()
        runtime/proc.go:254 +0x325 fp=0xc00008bfe0 sp=0xc00008bf50 pc=0x4473e5
runtime.goexit({})
        runtime/asm_amd64.s:1700 +0x1 fp=0xc00008bfe8 sp=0xc00008bfe0 pc=0x483561

goroutine 2 gp=0xc0000028c0 m=nil [force gc (idle)]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
        runtime/proc.go:435 +0xce fp=0xc000087fa8 sp=0xc000087f88 pc=0x47b2ee
runtime.goparkunlock(...)
        runtime/proc.go:441
runtime.forcegchelper()
        runtime/proc.go:348 +0xb8 fp=0xc000087fe0 sp=0xc000087fa8 pc=0x447658
runtime.goexit({})
        runtime/asm_amd64.s:1700 +0x1 fp=0xc000087fe8 sp=0xc000087fe0 pc=0x483561
created by runtime.init.7 in goroutine 1
        runtime/proc.go:336 +0x1a

goroutine 3 gp=0xc000002c40 m=nil [GC sweep wait]:
runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
        runtime/proc.go:435 +0xce fp=0xc000089f80 sp=0xc000089f60 pc=0x47b2ee
runtime.goparkunlock(...)
        runtime/proc.go:441
runtime.bgsweep(0xc000096000)
        runtime/mgcsweep.go:276 +0x94 fp=0xc000089fc8 sp=0xc000089f80 pc=0x42d434
runtime.gcenable.gowrap1()
        runtime/mgc.go:204 +0x25 fp=0xc000089fe0 sp=0xc000089fc8 pc=0x4216e5
runtime.goexit({})
        runtime/asm_amd64.s:1700 +0x1 fp=0xc000089fe8 sp=0xc000089fe0 pc=0x483561
created by runtime.gcenable in goroutine 1
        runtime/mgc.go:204 +0x66

goroutine 4 gp=0xc000002e00 m=nil [GC scavenge wait]:
runtime.gopark(0xc000096000?, 0x2b272a0?, 0x1?, 0x0?, 0xc000002e00?)
        runtime/proc.go:435 +0xce fp=0xc00009df78 sp=0xc00009df58 pc=0x47b2ee
runtime.goparkunlock(...)
        runtime/proc.go:441
runtime.(*scavengerState).park(0x3fa2840)
        runtime/mgcscavenge.go:425 +0x49 fp=0xc00009dfa8 sp=0xc00009df78 pc=0x42aec9
runtime.bgscavenge(0xc000096000)
        runtime/mgcscavenge.go:653 +0x3c fp=0xc00009dfc8 sp=0xc00009dfa8 pc=0x42b43c
runtime.gcenable.gowrap2()
        runtime/mgc.go:205 +0x25 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x421685
runtime.goexit({})
        runtime/asm_amd64.s:1700 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x483561
created by runtime.gcenable in goroutine 1
        runtime/mgc.go:205 +0xa5

[kapitainsky]

runtime: fatal error: mcall called on m->g0 stack on Windows

Looks like it is known golang issue. Some AMD CPU incompatibility.

Conclusion is unfortunately that:

The root cause of the problem is still uncertain, with possibilities ranging from a Go bug to a processor bug.