@AudriusButkevicius - I’m not allowed to post back to the original topic at Syncing Getting Stuck, but: I’ve got a deadlock for you!
Panic at 2017-02-02T10:01:35Z panic: deadlock detected at fmut ===fmut=== not held (writer) at model\model.go:589 goid: 313 for 5m3.4150087s (reader) ===pmut=== not held (writer)
What do you want me to do with the log files?
You can attach them here. If compressed to zip, you can just drag and drop into a post (probably, browser ymmv etc).
Ok… Nothing sensitive gets logged then? I can see it’s full of device ids, and the folder names are my customers, but… here you go:
syncthinglogs.zip (1.8 MB)
Thanks. Good log.
It’s hung because fmut is held by NeedSize, called by the GUI. NeedSize isn’t making progress because it’s blocked on a progress emitter’s DownloadProgress method. The progress emitter isn’t making progress (hah) because it’s locked sending progress messages. Sending progress messages is taking a long time because the underlying connection is blocked in IO wait.
In other words, this is a network stall. We should have a write timeout somewhere that fires before this happens, ideally… Unfortunately I think we have a couple of abstraction layers that don’t know about timeouts, between the place where it would be set and where it would get used. 
More generally, perhaps the progress emitter should be able to answer this question even when blocked sending messages. (cc @AudriusButkevicius) Also we should probably try to avoid holding those locks over network operations. But this one was deep and non-obvious…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.