How to safely downgrade on Android?

Support Android
1

I recently upgraded syncthing-android from 1.27.6 to 1.27.6.2 and it doesn’t work right anymore.

I manually downloaded the 1.27.6 apk from f-droid.org, but Android won’t let me just install it over top of 1.27.6.2.

What’s the recommended method of downgrading? Can I just export my syncthing config through the app, uninstall 1.27.6.2, install 1.27.6, and import my config, while leaving my files in place?

Note that I have a mix of send-receive and send-only folders on this device. I know some of them are out of sync by now. Some files have changed on the local device, however I don’t think there are any changes on remote devices since the last sync.

Are there any risks I should be aware of? I’ll backup important files ahead of time, but I’d still like to make it as smooth as possible.

Thanks!

2

You cannot downgrade apps reliably on Android (unless the device is rooted, which allows you to fully back up and restore app data). With the Syncthing app’s built-in export/import functionality, you basically back the config up but not the database.

This means that if you were in the middle of synchronisation, e.g. you modified and deleted some files locally, and those changes haven’t been synced to other devices yet, then after you restore the config on a new installation, Syncthing will treat the modified files as conflicts, which you’ll need to resolve manually, and the deleted files will be re-downloaded from other devices.

Can you describe what the issue is specifically? There should be zero difference between these two versions of the app. Also, v1.27.10 is already available on F-Droid, so you may want to try upgrading to the current version and see what happens first.

3

My device is rooted, and I actually happen to have an oandbackup of syncthing from before upgrading to 1.27.6.2, however the local filesystem is definitely out of sync from the state of the database at that time. I didn’t mention it because it seemed even more risky than starting with an empty database, but maybe it’s worth considering?

That’s pretty much what I was afraid of. However, in this specific case, it might not be that bad. Since there are no changes on the remote side since the last sync, and since the newest file wins, I should be able to simply delete all *.sync-conflict-* files, and I should end up back where I started, right?

I don’t feel great about it, but it might be the best option in this case.

That’s what I thought, too. But it worked fine a week ago, I upgraded to 1.27.6.2, and now it doesn’t work. Same config, same folders… sure, some files were added and modified but it’s roughly the same amount of data as it was before. I can’t think of anything else that could have caused it.

Basically, it can’t scan large directories (I’m talking like 2-5GB) anymore. Usually within seconds to minutes, the daemon will stop responding; the daemon log is blank, Android log says “connection refused” on API requests, and the web UI says ERR_CONNECTION_REFUSED. When I restart it, sometimes it will say “The daemon is taking very long to load” or something like that.

If I quickly press pause on the large folders while it’s starting up, I can get it to run normally and sync small folders as long as the large ones are paused. As soon as I unpause one of them, the the daemon will soon stop responding again. I should note that even scanning small folders takes much longer than it used to.

One time I was able to get it to successfully scan and sync a 4GB directory, after dozens of tries. Haven’t been able to since. (Again, 1.27.6 worked fine with these very same folders.)

I turned on the “scanner” STTRACE option, but I only have limited time before the daemon stops responding and the daemon log goes blank (“— beginning of main”).

I upgraded just now, but it seems to be having the exact same problem. :sob:

4

It’s safe to back the database up and restore it if you do it with everything up to date after shutting Syncthing down, however you definitely should not restore the old version. You will end up with corrupted folder states that can only be fixed by resetting the database anyway.

This is strange. Please keep in mind that there is no difference between v1.27.6.0 and v1.27.6.2 at all (i.e. literally only the version number differs), and with v1.27.10, the app is still the same, only the Syncthing binary has been updated.

I would try to export the configuration, reinstall the app using the newest version, and then import the configuration before downgrading to the old one first.

5

I have the same issue since 1.27.6.2: “connection refused”, and the web interface doesn’t work either (it can’t find the app on localhost). I’ve had to jump back to 1.27.6 from the last two upgrades on F-Droid.

6

Could you try using the official app release from https://github.com/syncthing/syncthing-android/releases and see if the same problem persist there? Please note that you will probably need to uninstall the F-Droid version in order to do so first.

7

Thanks for replying so fast on a Saturday!

Done. Same weird behavior. At first the app didn’t like my backed up config. It became unresponsive, offering me to look at the log, which only displayed “------- beginning of main”. :face_with_peeking_eye:

Killed it from the OS settings and restarted. This time the config worked, it started syncing well and suddenly I saw the dreaded message on the other side (PC): “connection refused”. And then “no route to host”.

On the phone it just keeps saying “scanning” on some directories, no error mentions, but if I open the web interface: “Website not available (…) net::ERR_CONNECTION_REFUSED”.

8

Is there a log file saved on the internal storage? It should be located at Android/data/com.nutomic.syncthingandroid/files/syncthing.log. If you find it, please share the content here (using the preformatted text </> option).

9

Yes, there it is. Should I share its whole content? It shows some directory names and IPs. Probably not big deal, but I would like to keep them to myself.

Seeing this though:

fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)
10

The whole log would be useful. You can obfuscate device/folder names, paths, addresses, etc.

11

Oops, was going to post it, but the forum alerts:

An error occurred: Body is limited to 32000 characters; you entered 177807.

12

You should be able to upload the file as a whole (using drag and drop). You may need to rename the extension from .log to .txt.

13

Thanks, tomas. Here you go.

syncthing.log (173.6 KB)

14

Yeah, so there is panic starting from

runtime: pointer 0x92c9c3c0 to unused region of span span.base()=0x90a1e000 span.limit=0x90a20000 span.state=1
runtime: found in object at *(0x91275540+0x4)
object=0x91275540 s.base()=0x91274000 s.limit=0x91276000 s.spanclass=12 s.elemsize=64 s.state=mSpanInUse
 *(object+0) = 0xb1bd57ec
 *(object+4) = 0x92c9c3c0 <==
 *(object+8) = 0x20
 *(object+12) = 0x92c88d40
 *(object+16) = 0x31
 *(object+20) = 0x40
 *(object+24) = 0x2
 *(object+28) = 0x913d74a0
 *(object+32) = 0x20
 *(object+36) = 0x20
 *(object+40) = 0x913d74a0
 *(object+44) = 0x0
 *(object+48) = 0x0
 *(object+52) = 0x0
 *(object+56) = 0x0
 *(object+60) = 0x0
fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)

Let’s wait for someone more knowledgeable to have a look at it.

3 Likes
15

I guess in theory I could take an oandbackup of the current database, and replace just the app .apk with the old one, and restore the modified zip file. The thing is, I’m not even sure if I can get the database in sync with the current filesystem, because syncthing keeps crashing during scanning.

I guess @tagomago is having better luck than me with the logs. I restarted the app a couple of times and checked the log file after the daemon stopped responding. I don’t have it in front of me at the moment, but I’m pretty sure every time it was just debug output about what file it was scanning, and that was it. I didn’t see any errors or stack traces or anything like that. It looked to me like normal output right up to the end of the file.

Are there any STTRACE options that might help besides “scanner”?

16

Good news, it finally logged a crash. The bad news, it’s different than what @tagomago got.

syncthing.log.txt (122.3 KB)

17

@imsodin I’m really sorry to bother you, but if you find some free time, would you be able to have a look at these panics? The one from https://forum.syncthing.net/t/how-to-safely-downgrade-on-android/22616/13 comes from the app built by us, the one from https://forum.syncthing.net/t/how-to-safely-downgrade-on-android/22616/16 seems to be the F-Droid build. Both panics come from the newest Syncthing v1.27.10.

18

Neither of those crashes are anything that makes sense from an “our code” perspective. It looks like memory corruption due to hardware failure or by some C/unsafe package linked in with bugs. They’re not actionable from my PoV.

19

Thanks for looking into it! Weird… :thinking: Maybe related to (in my case) ST being run under LineageOS on a rather old device (Nexus 5). Well, in any case I guess I’ll have to sit on 1.27.6 for a while, which works fine for me.

20

You’re not going to believe this, but I captured three more crashes, all different than the first. A blocked read on free polldesc, a panic during panic, and an illegal instruction.

syncthing4.log (134.9 KB) syncthing5.log (15.3 KB) syncthing6.log (149.4 KB)

Thanks from me as well. I also have a quite old device (Nexus 6). Since 1.27.6 is working for you, I think I’m going to bite the bullet and try downgrading, fingers crossed.

If it was memory corruption due to hardware failure, wouldn’t it also affect 1.27.6, as well as other apps and even the OS itself? The part about a buggy C/unsafe package being linked in, I don’t know how any of that works on Android, so I guess that’s what I’m going with.

If there’s nothing you can do, there’s nothing you can do. It just seems really odd that two of us started experiencing the same problem after such a minor upgrade. Thanks for looking into it nevertheless.