"panic: potential deadlock detected at fmut (long timeout)" possibly when trying to hibernate device

[tomasz86]

I’ve found this panic log from a few days ago. This probably happened when the device was trying to enter hibernation, and something must have failed in the process, because I found it later with the battery drained completely.

Panic at 2023-10-16T06:14:27+02:00
panic: potential deadlock detected at fmut (long timeout):


goroutine 46 [running]:
github.com/syncthing/syncthing/lib/model.(*deadlockDetector).watchInner(0xc00008e9f0, {0x1a7e162, 0x4}, 0xc0018e1380)
	github.com/syncthing/syncthing/lib/model/util.go:93 +0x587
github.com/syncthing/syncthing/lib/model.(*deadlockDetector).Watch.func1()
	github.com/syncthing/syncthing/lib/model/util.go:59 +0x68
created by github.com/syncthing/syncthing/lib/model.(*deadlockDetector).Watch in goroutine 1
	github.com/syncthing/syncthing/lib/model/util.go:47 +0x116

panic-20231016-061427.log (692.5 KB)

Syncthing is self-compiled from https://github.com/tomasz1986/syncthing/tree/5ba56573ea97b1860bd96e5f6e34f95ef5cb4461 (v1.25.0 with a few custom tweaks), and the OS is Windows 10 x64.

Is this something serious or should I just ignore it?

[AudriusButkevicius]

This is just a side-effect of the deadlock detection mechanism being caught at a bad time. Not sure how much value that mechanism provides anymore, but it also could probably fixed to handle things like this better.

[calmh (Jakob Borg)]

It also only happens because your custom tweaks makes Syncthing think it’s running a development version. It doesn’t do this in release builds.

[tomasz86]

What’s strange is that I use my builds with the environment variable STDEADLOCKTIMEOUT set to 0 as suggested in the past in https://github.com/syncthing/syncthing/issues/7764, yet this deadlock still happened.

[calmh (Jakob Borg)]

Yeah that doesn’t disable it (for dev builds).