On my “subscribed” page, if I scroll down, the app crashes. Not sure of anything more than that. But it’s definitely repeatable for me.
Device information
Sync version: v23.11.29-22:27
Sync flavor: googlePlay
View type: Smaller cards
Device: ASUS_AI2302
Model: asus ASUS_AI2302
Android: 14
It looks like someone has posted a malformed image that is causing the issue.
It’s this post
This crashes for me
Removed by mod
That’s what happened to me. Repeated attempts to load it made a prompt to clear cache appear. I haven’t had a full crash yet. Maybe there’s other offending posts. This one is in thee communities though so it could hit a lot of people.
Edit: it’s something to do with the user. They made another post in cryptography that breaks sync for me too.
They’re on a different activitypub platform.
I’d be cautious.
These malformed images may be malicious.
A malformed image should not cause a crash. I’m not sure what libraries Sync uses for this stuff, but the bug should be reported upstream (assuming it’s not just some exception mishandling going on in Sync.)
I don’t think this has anything to do with malicious images. From my crash logs, it looks like a simple database inconsistency issue:
E AndroidRuntime: FATAL EXCEPTION: main E AndroidRuntime: Process: io.syncapps.lemmy_sync, PID: 6602 E AndroidRuntime: java.lang.ArrayIndexOutOfBoundsException: length=4; index=4 E AndroidRuntime: at uc.a.d(Unknown Source:49) L E AndroidRuntime: at a9.a.containsKey(Unknown Source:2) E AndroidRuntime: at z8.p.k(Unknown Source:2) L E AndroidRuntime: at wc.e.x0(Unknown Source:8) E AndroidRuntime: at wc.e.E(Unknown Source:7) E AndroidRuntime: at xc.d$g$a.a(Unknown Source:3) E AndroidRuntime: at xc.d$g$a.onLoadComplete(Unknown Source:2) E AndroidRuntime: at android.content.Loader.deliverResult(Loader.java:157) E AndroidRuntime: at android.content.CursorLoader.deliverResult(CursorLoader.java:117) E AndroidRuntime: at android.content.CursorLoader.deliverResult(CursorLoader.java:47) 03-04 E AndroidRuntime: at android.content.AsyncTaskLoader.dispatchOnLoadComplete(AsyncTaskLoader.java:274) E AndroidRuntime: at android.content.AsyncTaskLoader$LoadTask.onPostExecute(AsyncTaskLoader.java:97) E AndroidRuntime: at android.os.AsyncTask.finish(AsyncTask.java:771) E AndroidRuntime: at android.os.AsyncTask.-$$Nest$mfinish(Unknown Source:0) E AndroidRuntime: at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:788) E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:106) E AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:201) E AndroidRuntime: at android.os.Looper.loop(Looper.java:288) E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7937) E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method) E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:854)They’re on a platform I don’t recognise.
I’m guessing that a non-Lemmy server doesn’t provide some optional fields that Lemmy servers always provide, or that it provides some unexpected but valid data points in the API. The API docs aren’t exactly very detailed, so I wouldn’t be surprised if LJD assumed some optional field to always be present (because on every post on Lemmy that has been the case).
I took a look at the JSON Lemmy generates and it seems perfectly fine. Unfortunately, Sync is obfuscated so I can’t get a clue at what object is malformed in the database to see what could be causing this.
If you block the user, it seems to fix the problem, but you’ll have to block them on another app, or via browser, obviously.
Pain in the ass