Personally I can reliably cause Syncthing to crash by starting while connected to a network that locally hosts another Synthing node (both the node and app are on v1.26.1).
I have finally got round to capturing the logcat output of the crash (rather than the slightly truncated output in the Sycthing-Fork app). The full logcat can be found here: Syncthing-Fork v1.26.0 · GitHub
But the opener is:
11-19 11:32:51.661 11506 21478 W SyncthingNativeCode: panic: runtime error: invalid memory address or nil pointer dereference
11-19 11:32:51.661 11506 21478 W SyncthingNativeCode: [signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x637d5ee060]
Please let me know if you need anymore info / logging date / experimentation to track this down. Others in the GitHub issue I am sure would be happy to help.
I tried resetting the database and delta indexes and this didn’t change anything.
The odd thing is it only crashes if Syncthing starts while directly connected to the network with the local node. If started offline and the connected it runs. If connected to another network e.g mobile data and then connected to the local node after starting it also runs.
I think this is another fmut locking problem: Before the entries in folderCfgs and folderRunners for the same key/folder were removed under a single lock, after stopping the folder. Now stopping the folder and removing it from the map is a single operation. For one it happens with just a read-lock, but even with a full lock it’s still problematic: After it stopped, the runner isn’t present anymore while the folder-config still is.
The index handler in turn looks at the folder config that is not paused, thus assumes the runner has to be present → nil deref on the runner.
While a bit tedious, the only way I see right now that we can fix this is to add a method on the service map to stop the service, but not remove it yet.