Syncthing is crashing

Hi there! I have a problem with my Syncthing installation. It works on my old NAS with 1Gb RAM and weak 2core CPU.

Linux 6.17.7-mvebu-tld-1 #1 SMP PREEMPT Tue Nov 4 16:19:08 PST 2025 armv7l GNU/Linux

syncthing v2.1.0 “Hafnium Hornet” (go1.26.3 linux-arm)

free -h total used free shared buff/cache available Mem: 996Mi 478Mi 115Mi 884Ki 651Mi 518Mi Swap: 6.0Gi 74Mi 5.9Gi

So sometimes Syncthing is crashing when new device appearing in LAN (PC booted up) and sometimes randomly. I disabled all the services and left only Syncthing+updated it till the latest version. But from what I could see, it works unstable.

For now, there is only 1Tb folders/files, not so much. I found various crash-logs but they are looking the same. The only difference in the last folder, where Syncthing crashed.

panic-20260418-163125.reported.log (158.3 KB)

What also can I provide to find out where is the issue?

PS: I added loooong time ago that Options - Max Folder Concurrency - 1

I’m seeing that same crash from a few different users in the crash reporting, all on linux-arm (32 bit). Not sure what to make of that, unfortunately.

I asked AI about that and here is the responce:

Your Syncthing application is crashing due to an internal error within the Go programming language itself, which the program is written in.

What exactly is the problem?

The log clearly shows a critical error:

fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)

To put it simply, an automatic “Garbage Collector” runs inside the program. Its job is to go through the device’s memory, look for unneeded data, and delete it to free up space. At the moment of the crash, this collector stumbled upon a “broken” pointer (a memory reference) that led nowhere or pointed to an incorrect memory area. Out of panic and the inability to continue working, the program shut down unexpectedly (this is called a Panic).

Judging by the first line of your log, you have Syncthing version v2.0.15 installed, which was built using go1.26.0 for the 32-bit linux-arm architecture (for example, a Raspberry Pi or another similar single-board computer / old server).

This is a known and confirmed bug. In Go version 1.26, the developers introduced a new garbage collection mechanism (called Green Tea GC or greenteagc). As it turned out, this mechanism contains bugs on 32-bit systems (386, ARM) and periodically corrupts memory itself, causing the exact same crashes as seen in your log (mgcmark_greenteagc.go -> badPointer). The Syncthing program itself has nothing to do with this — it became a victim of a bug in the development tools.

How to fix it

You can solve this problem in a few ways:

The easiest and fastest way (disable the problematic garbage collector):

You need to run Syncthing with a special environment variable that tells the system: “Use the old, time-tested way of cleaning up memory.”

The variable is called: GOEXPERIMENT=nogreenteagc

  • If you run Syncthing manually from the console, the command should look like this:

Bash

GOEXPERIMENT=nogreenteagc syncthing

  • If Syncthing runs as a service (a systemd service unit), you need to edit the service file (usually via the command sudo systemctl edit syncthing@your_name.service) and add this line to the [Service] section:

Ini, TOML

Environment=GOEXPERIMENT=nogreenteagc

After that, restart the service (sudo systemctl restart syncthing). This will completely protect the program from this specific crash.

Update Syncthing:

The Go developers fixed this serious bug in Go version 1.27. Check for Syncthing updates for your distribution. As soon as they release a version built on a newer Go version (1.27 and higher), the crashes will stop on their own.

Use the 64-bit version (if your device allows it):

If your processor supports 64-bit instructions (ARM64), it is highly recommended to reinstall your operating system to a 64-bit one and use Syncthing for arm64. This problem exclusively affects 32-bit builds.

I’ll try Environment=GOEXPERIMENT=nogreenteagc and will get back.

systemctl status syncthing@syncthinguser | grep PID

cat /proc/4387/environ | tr ‘\0’ ‘\n’ | grep GOEXPERIMENT
GOEXPERIMENT=nogreenteagc

but looks like it didn’t help me. Syncthing is crashing sometimes. Any ideas? Anyone?

Does the panic log contain the same entry?

Frankly, if you’re seeing this repeatedly I’d suspect you have bad RAM in that machine.

yes, nothing has changed.

I don’t know if your NAS supports a RAM test; if it doesn’t, you might want to try testing the memory in another machine. Or for that matter, a 1GB DDR3 RAM stick is costing $10 with free shipping on the 'bay (make sure to get RAM compatible with your device). If a replacement RAM stick solves the problem, you’re in great shape.

If your NAS supports more RAM, that might be a good idea while you’re at it, but I want to be clear this doesn’t look to me like a “more RAM will fix it” sort of problem.

No, there is no chance to swap the memory, it’s soldered. And yes, Debian has a memtester utility. I tested NAS’s RAM and everything looks fine from memory perspective.

What I did last time:

  1. RAM was tested (ok, no issues were found)
  2. I updated all the software
  3. I updated the kernel till the latest version - 6.19.9
  4. I looked up for errors in Debian’s logs (no errors were found)
  5. Compiled Syncthing v2.1.1-dev.8.g3962a237 with latest go1.26.3
  6. Enabled ZRAM

from the first glance I can see, that Syncthing crashing not so often, but the problem remains.

I started seeing these crashes as well using Syncthing 2.1.0 on ARMv7 (official Syncthing repo on Debian 13), about once a day during a phase that was rather heavy on syncs. It’s a variation of

fatal error: found pointer to free object

goroutine 3 gp=0x4804c88 m=63 mp=0x4d19008 [running]:
runtime.throw({0x1fd8ae, 0x1c})
	runtime/panic.go:1229 +0x34 fp=0x48516b4 sp=0x48516a0 pc=0xcc1970
runtime.(*mspan).reportZombies(0xab627ab0)
	runtime/mgcsweep.go:893 +0x370 fp=0x48516ec sp=0x48516b4 pc=0xc69cb0
runtime.(*sweepLocked).sweep(0x48517ac, 0x0)
	runtime/mgcsweep.go:673 +0xb6c fp=0x485178c sp=0x48516ec pc=0xc6936c
runtime.sweepone()
	runtime/mgcsweep.go:396 +0x108 fp=0x48517c8 sp=0x485178c pc=0xc68508
runtime.bgsweep(0x4876000)
	runtime/mgcsweep.go:300 +0xbc fp=0x48517e4 sp=0x48517c8 pc=0xc68200
runtime.gcenable.gowrap1()
	runtime/mgc.go:214 +0x1c fp=0x48517ec sp=0x48517e4 pc=0xc545ac
runtime.goexit({})
	runtime/asm_arm.s:873 +0x4 fp=0x48517ec sp=0x48517ec pc=0xcc8fb0
created by runtime.gcenable in goroutine 1
	runtime/mgc.go:214 +0x74

and

fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)

runtime stack:
runtime.throw({0x221727, 0x3e})
	runtime/panic.go:1229 +0x34 fp=0xad65fb4c sp=0xad65fb38 pc=0xcc1970
runtime.badPointer(0xa9532a88, 0x91c959d, 0x0, 0x0)
	runtime/mbitmap.go:1334 +0x88 fp=0xad65fb6c sp=0xad65fb4c pc=0xc4aff8
runtime.findObject(0x91c959d, 0x0, 0x0)
	runtime/mbitmap.go:1386 +0xc8 fp=0xad65fb84 sp=0xad65fb6c pc=0xcbfbe0
runtime.scanObjectsSmall(0x8784000, 0x20, 0xf4, 0x483e980, 0xad65fbec)
	runtime/mgcmark_greenteagc.go:1056 +0x37c fp=0xad65fbd0 sp=0xad65fb84 pc=0xc60f8c
runtime.scanSpan(0x87840a6, 0x483e980)
	runtime/mgcmark_greenteagc.go:897 +0x274 fp=0xad65fc80 sp=0xad65fbd0 pc=0xc6071c
runtime.gcDrain(0x483e980, 0xb)
	runtime/mgcmark.go:1333 +0x3ac fp=0xad65fcd4 sp=0xad65fc80 pc=0xc5d7d4
runtime.gcDrainMarkWorkerFractional(...)
	runtime/mgcmark.go:1184
runtime.gcBgMarkWorker.func2()
	runtime/mgc.go:1879 +0x8c fp=0xad65fd00 sp=0xad65fcd4 pc=0xc58008
runtime.systemstack(0x1000000)
	runtime/asm_arm.s:315 +0x60 fp=0xad65fd04 sp=0xad65fd00 pc=0xcc77ac

Before upgrading to 2.1.0 I never saw any of these.

I’m not pretty sure, but it looks like 1st version was working without issues.