Syncthing 1.26 crashing on Android in Syncthing-Fork

Development
1

I’m not sure this is the right place to post this to please move as needed or tell me to open a GitHub issue.

Since v1.26.0 the Syncthing native component (the Golang app not @Catfriend1 Android wrapper) has been crashing for multiple people. There is a GitHub issue here: syncthing crashes since v1.26.0.0 · Issue #1027 · Catfriend1/syncthing-android · GitHub that describes this in more detail.

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.

1 Like
2

So to sum up the issue: Some users are affected when Syncthing connects to another node.

A workaround has been discovered that pausing the folder on another node may avoid the crash on the Android side.

I’ve experimented a little with my phone and setup, but never got SyncthingNative to crash.

The relevant log had been provided here:

3

As an add-on to @blu3id report, for me this seems to happen only for Android’s default Camera folder. Sharing a different folder doesn’t trigger a crash in neither Send Only nor Send & Receive mode.

4

What about having a backup at hand and resetting the database? Does that help?

5

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 don’t know the significance of this.

1 Like
6

With the nil-deref location it was finally possible to investigate this panic - thanks for that. I found something that’s likely the culprit here: Nil deref in index handler · Issue #9234 · syncthing/syncthing · GitHub

3 Likes
7

Hi @imsodin ,

I’m still getting native crash reports of the fork app users. We now have a new log regarding 1.27.0 stable.

Could you please check and provide feedback on that?

Full log: https://github.com/Catfriend1/syncthing-android/files/13601590/syncthing.log

The crash is at : 15-48-47

Thank you.

8

@blu3id could you please edit the title to say 1.27.0

9

No unfortunately. I think I’m too low a Trust Level. Hopefully one of the @moderators can help?

10

You don’t though, because that log says

12-07 15:49:15.649  9007 28584 I SyncthingNativeCode: [start] INFO:
 syncthing v1.26.1 "Gold Grasshopper" (go1.21.4 android-arm64)
 vagrant@bullseye 2023-11-15 09:54:03 UTC [noupgrade, stguiassets, stnoupgrade]
11

Oh, sorry I was too fast to forward it here :sob::see_no_evil:. I’ll ask the user to upgrade.

Ref still crashes with Code 2 (dont know what it means) V1.27, Pixel Pro7, Android 14 · Issue #1050 · Catfriend1/syncthing-android · GitHub

12

So still able to reliably cause a crash as mentioned up thread. My captured logcat:

3 Likes
13

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.

1 Like
14

Hopefully fixed in Syncthing v1.27.1-rc.1 which should become a real release in a few days, unless badness is discovered.

2 Likes
15

Thanks, that was really fast :heart_eyes:. I’ ll try to build a test APK later today, hopefully I get to do this before our local christmas market starts :christmas_tree:

1 Like
16

… Built and released :slight_smile:

17

Same on the other app (well hanging in play review).

1 Like
18

Thanks @imsodin !

Qorron reported back on github that the issue is now fixed by 1.27.1.0

2 Likes
19

Thanks, this seems to have fixed things for me. I can no longer reliably cause crashes :grinning:

2 Likes
20

Same on the other app (well hanging in play review)