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

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/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?

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.

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.

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.

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

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