This log is the only one that I was able to grab from adb because I was not aware that the binary crashed.
Basically the gui was working but the backend was not, because there was no web server.
Anway I hope it helps with figuring out why it crashed.
Actual crash message has already rolled off, so it’s not very useful.
Also lacks the start of the crash, and lacks any time stamps. It’s super unclear what happened from this kind of log output. Did the android app crash and syncthing go down as an effect of it? Was it the other way around? Was something killed due to idle or out of memory or something? @nutomic/@zillode is there no way to get better log output than this out of the system so these things can be properly debugged? I’m not blaming your for this @totoba.
It is hard to know what exactly happened because like most user I d onot just sit in front of the device and wait it to crash. Sometimes it takes a long time to crash sometimes not, really hard to tell. The only way I am able to catch to see if the binary (syncthing) crashed when I load the web page on my desktop (I am using adb port forwarding to access the device’s server page)
It was the syncthing binary that crashed in these 2 instances and the syncthing gui was still running and it was pretending that everything was running smooth like you would not know that the back end was not running properly in the background.
I am thinking that the recent changes to the hashing is taking a big toll on this device becasue stuff is also taking very long time compared to before but hard to say.
This device is Android 4.2. This is not necessarily a fast and great memory device, it is an erader. However ST has always worked somewhat, I was not getting this much of crashes and slow syncing like now.
And somehow the hashing speed is pretty dismal, not sure if it it the io or the cpu
I/SyncthingNativeCode(19944): [EMRN4] 15:46:30 INFO: Single thread SHA256 performance is 6.5 MB/s using crypto/sha256 (6.3 MB/s using minio/sha256-simd).
I/SyncthingNativeCode(19944): [EMRN4] 15:46:33 INFO: Hashing performance with weak hash is 5.17 MB/s
I/SyncthingNativeCode(19944): [EMRN4] 15:46:35 INFO: Hashing performance without weak hash is 6.37 MB/s
I/SyncthingNativeCode(19944): [EMRN4] 15:46:35 INFO: Weak hash enabled, as it has an acceptable performance impact.The Syncthing log is located in /storage/emulated/0/Android/data/com.nutomic.syncthingandroid/files.
Thanks but that does not have the crash logs, it is the log for the currently running syncthing. I will see if I get another crash and see if this one usefuly.
On the other hand I get binary crashing in the background since the start of the project. And this is the most frustrated part of the android port unfrotunately. Because most of the time the user is not aware of the binary not working (since the gui is working) therefor the syncs stinks druing that time period until the user finds it out which is harder to find out because most android users of this app wont tcheck the web page frequently.
Should not the Gui app check to see if the binary is working properly if not reinitiate the binary properly?
If any user, ever, could give us a crash log of this we might fix it. I keep hearing about it but it never goes beyond hearsay, which is quite frustrating.
I am trying here. Like you pointed out, it is not easy to get the crash logs on mobile devices for various reasons, mostly not easy to detect the crash.
It would be very nice if the app detects the binary crashes and informs the user that binary crashed nad if the user wants to share whatever appropriate crash log with the devs then one can take that an email, post it on the forum etc. Otherwise i think it is just a sneaky situation where not easy to detect.
Ok sorry another useless post.
Here the binary suddenly crashes or rather disappears, and the syncthing.log is cutoff there so this is what I gathered from adb, as you can see the inotify is failing to scan due to binary not running.
The web server is not available and the Gui pretends that everything is fine.
E/SyncthingRunnable(19944): [EMRN4] 15:49:57 INFO: Established secure connection to XXXXX-43OVXI7-N7JMPVT-VJIXNHK-J2AW3XR-XRNUQCJ-T3VYBHN-XXXXX at 192.168.5.xxx:47526-xx.xx.170.xx:22000 (tcp-client) (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
E/SyncthingRunnable(19944): [EMRN4] 15:49:57 INFO: Device XXXXX-43OVXI7-N7JMPVT-VJIXNHK-J2AW3XR-XRNUQCJ-T3VYBHN-XXXXX client is
W/ApiRequest(19944): Request to https://127.0.0.1:8384/rest/db/scan?folder=SYNC&XXXXXXXXXXXXXXXX failed: java.net.ConnectException: failed to connect to /127.0.0.1 (port 8384) after 2500ms: isConnected failed: ECONNREFUSED (Connection refused)
The actual syncthing log does not have any kind of crash information, it just looks like standard scanning, connecting until it is cut off by the crash.
The bottom line is that we also need the crash logs of the binary saved somewhere otherwise as a user I cant help out here.
Yes, this is the file that should help us debug this issue (syncthing.log). It always appends. However, it is limited to 1K lines which might be too short?
How about this ?
https://paste.debian.net/hidden/d247ff26/
As you see it looks normal and suddenly it goes south.
That’s an excellent trace that points to an actual problem of one kind or the other. Thanks.
My first question though, is what version of Syncthing this really is and why it’s running with the deadlock detector…
This is the Fdroid version which is v0.14.22-rc.1+12…e7f according to the info on the left tab. The app version is 0.9.6
I do not even know what deadlock detector is, i just installed the app and used it> Is it part of android version?
Ah. No, it’s something that Syncthing does internally in development versions, which that apparently is. It helps narrow down deadlocks, but can also cause false positives which results in crashes. I can’t say which of the two that is without staring deep into the abyss, but I’ll do that tomorrow or so.
I was wondering what the 0.14.22…+dev line was in the usage statistics.
Yes, I think we may exceed that in some backtraces, and the most important info is always in the first couple of lines. 10k should be safe I think.
Here is the extended version. I let the crash keep going for a while. I just did not kill the Gui app when it died.
Wow, I didnt think you could get more than 1000 lines of useful info in any case. Will change to 10k.
Edit: I’ve also added a notification that is shown when Syncthing crashes, and directly opens the log file.
It’s not so much that there are 5000 lines of useful info, more that there can be 5000 lines and they’re all useless if we’re missing the first five.