What happened?
Summary
Syncthing crashes repeatedly on Windows with a STATUS_ACCESS_VIOLATION (0xc0000005) exception inside the SQLite cgo bindings. The crash always occurs in the same call chain: folderSummaryService.calculateSummaries → folderDB.CountNeed → folderDB.needSizeRemote → SQLiteRows.nextSyncLocked → _Cfunc__sqlite3_step_internal.
The fault address varies across crashes (e.g. 0x0, 0x7ff6fdb1d478, other addresses), which is consistent with a race condition on a prepared statement or database handle in the cgo/SQLite layer.
Expected behavior
Syncthing runs without crashing while computing folder sync summaries in the background.
Steps to reproduce
- Run Syncthing v2.0.16-rc.1 on Windows 11
- Have at least one folder configured for sync
- Syncthing crashes within seconds to minutes, always in the same stack
Notes
- Deleting the entire
index-v2/ database directory and forcing a full rescan did not fix the crash — it reappears immediately after rescan
- The crash pre-dates v2.0.16-rc.1; it appears to have existed for some time
- This is a cgo crash ("signal arrived during external code execution"), so it originates in C code (go-sqlite3 v1.14.34), not in Go code
- No existing GitHub issue was found for this specific stack trace
Syncthing version
v2.0.16-rc.1 (go1.25.7, windows-amd64)
Platform & operating system
Windows 11 (windows/amd64)
Browser version
No response
Relevant log output
Exception 0xc0000005 0x1 0x0 0x7ff6fdb1d478
PC=0x7ff6fdb1d478
signal arrived during external code execution
goroutine 85 gp=0xc000196280 m=6 mp=0xc000188600 [syscall]:
runtime.cgocall(...)
runtime/cgocall.go:369 +0x5e fp=0xc001a44ea8 sp=0xc001a44e70 pc=0x463cde
github.com/mattn/go-sqlite3._Cfunc__sqlite3_step_internal(...)
_cgo_gotypes.go:620 +0x56 fp=0xc001a44ec8 sp=0xc001a44ea8 pc=0x893356
github.com/mattn/go-sqlite3.(*SQLiteRows).nextSyncLocked(...)
sqlite3.go:2233 +0x53 fp=0xc001a44f08 sp=0xc001a44ec8 pc=0x898ef3
github.com/mattn/go-sqlite3.(*SQLiteRows).Next(...)
sqlite3.go:2205 +0x56 fp=0xc001a44f28 sp=0xc001a44f08 pc=0x898ea6
database/sql.(*Rows).Next(...)
sql.go:3197 +0x104 fp=0xc001a44f68 sp=0xc001a44f28 pc=0x6b1e24
github.com/syncthing/syncthing/internal/db/sqlite.(*folderDB).needSizeRemote(...)
folderdb_counts.go:100 +0xc6 fp=0xc001a44fd0 sp=0xc001a44f68 pc=0xb78226
github.com/syncthing/syncthing/internal/db/sqlite.(*folderDB).CountNeed(...)
folderdb_counts.go:38 +0x91 fp=0xc001a45008 sp=0xc001a44fd0 pc=0xb77b91
github.com/syncthing/syncthing/lib/model.(*folderSummaryService).sendSummary(...)
folder_summary.go:404 +0x137 fp=0xc001a450a0 sp=0xc001a45008 pc=0xd7aaf7
github.com/syncthing/syncthing/lib/model.(*folderSummaryService).calculateSummaries(...)
folder_summary.go:333 +0x10b fp=0xc001a450d8 sp=0xc001a450a0 pc=0xd7a8ab
github.com/syncthing/syncthing/lib/model.(*folderSummaryService).Serve(...)
folder_summary.go:90 +0x14a fp=0xc001a45110 sp=0xc001a450d8 pc=0xd799ca
What happened?
Summary
Syncthing crashes repeatedly on Windows with a
STATUS_ACCESS_VIOLATION(0xc0000005) exception inside the SQLite cgo bindings. The crash always occurs in the same call chain:folderSummaryService.calculateSummaries→folderDB.CountNeed→folderDB.needSizeRemote→SQLiteRows.nextSyncLocked→_Cfunc__sqlite3_step_internal.The fault address varies across crashes (e.g.
0x0,0x7ff6fdb1d478, other addresses), which is consistent with a race condition on a prepared statement or database handle in the cgo/SQLite layer.Expected behavior
Syncthing runs without crashing while computing folder sync summaries in the background.
Steps to reproduce
Notes
index-v2/database directory and forcing a full rescan did not fix the crash — it reappears immediately after rescanSyncthing version
v2.0.16-rc.1 (go1.25.7, windows-amd64)
Platform & operating system
Windows 11 (windows/amd64)
Browser version
No response
Relevant log output