[Bug]: App crashes (out of memory) on start up local session sync

[lukeIam]

What was the Problem?

Starting the android app always results in an app crash as long as the server is reachable.
I can see the full interface (also indicating the server is connected) and can even start playing an audiobook if I'm fast.
Then I get the Android message that ABS has crashed.

Workaround:

1. disable network connections
2. start abs and wait 10s
3. enable network again
4. use ABS as normal (no crash - everything works)

Steps to Reproduce the Issue

1. start ABS (no other apps running)

What was Expected?

No crash after start

Phone Model

Google Pixel 7

Phone OS

Android 15

Audiobookshelf App Version

Android App - 0.9.77-beta

Installation Source

Google Play Store

Additional Notes

App version 0.9.77-beta
Server Version: 2.17.7 (also occurred with an older version)

logcat -b crash:

01-12 12:00:28.370 31016 31169 E AndroidRuntime: FATAL EXCEPTION: OkHttp Dispatcher
01-12 12:00:28.370 31016 31169 E AndroidRuntime: Process: com.audiobookshelf.app, PID: 31016
01-12 12:00:28.370 31016 31169 E AndroidRuntime: java.lang.OutOfMemoryError: Failed to allocate a 140112784 byte allocation with 100663296 free bytes and 111MB until OOM, target footprint 520696000, growth limit 536870912
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at java.lang.StringFactory.newStringFromUtf16Bytes(Native Method)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at java.lang.StringUTF16.newString(StringUTF16.java:1141)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at java.lang.StringBuilder.toString(StringBuilder.java:475)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at org.json.JSONStringer.toString(JSONStringer.java:443)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at org.json.JSONObject.toString(JSONObject.java:703)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.server.ApiHandler.postRequest(ApiHandler.kt:64)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.server.ApiHandler.sendSyncLocalSessions(ApiHandler.kt:357)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.plugins.AbsDatabase.syncLocalSessionsWithServer$lambda$4(AbsDatabase.kt:232)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.plugins.AbsDatabase.$r8$lambda$pnHB3jg7r_TQOFKHlbjIVe6y0i0(Unknown Source:0)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.plugins.AbsDatabase$$ExternalSyntheticLambda0.invoke(Unknown Source:4)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.server.ApiHandler.syncLocalMediaProgressForUser$lambda$25(ApiHandler.kt:413)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.server.ApiHandler.$r8$lambda$DuqQfU3xJN73k-Ul8cnKrEZgHls(Unknown Source:0)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.server.ApiHandler$$ExternalSyntheticLambda12.invoke(Unknown Source:8)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.server.ApiHandler.getCurrentUser$lambda$0(ApiHandler.kt:150)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.server.ApiHandler.$r8$lambda$ZPxn1vUH6yoFRjSBbjSLl8U83eE(Unknown Source:0)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.server.ApiHandler$$ExternalSyntheticLambda14.invoke(Unknown Source:6)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at com.audiobookshelf.app.server.ApiHandler$makeRequest$1.onResponse(ApiHandler.kt:130)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
01-12 12:00:28.370 31016 31169 E AndroidRuntime:        at java.lang.Thread.run(Thread.java:1012)

[lukeIam]

@advplyr is there a way to get more logs out of the app?
Or anything else I can do to provide better information?

[nichwall]

What constitutes as reachable? LAN, reverse proxy over mobile network or another Wi-Fi network, VPN, etc?

[lukeIam]

What constitutes as reachable? LAN, reverse proxy over mobile network or another Wi-Fi network, VPN, etc?

Server ethernet connected to the access point (nginx reverse proxied) where the pixel is connected to -> no vpns active in this scenario.
"reachable" means for the connection status indicator in the app turns green + I can shortly stream an non-offline audiobook before the crash -> server connected and usable

But thinking about the error message says the crash happens during:
com.audiobookshelf.app.server.ApiHandler.sendSyncLocalSessions

There is something special: I listened to an offline book over that time span of ~3 weeks (start to end) without any server connection (no internet). Also when checking this book in the web browser it shows no progress nor history.

Could it be that the app is crashing when it tries to upload the listen history of this book? The books I started after is showing progress in the browser (but I'm still actively listening to it).

Looks I can fix this by reinstalling the app and sacrificing the listen history of a single book...
question: do you want to investigate this problem further or should I just (try to) fix my local problem?

Edit: 140112784 bytes ~= 140mb - quite a lot for some listen history

[advplyr]

Could it be that the app is crashing when it tries to upload the listen history of this book? The books I started after is showing progress in the browser (but I'm still actively listening to it).

Looks I can fix this by reinstalling the app and sacrificing the listen history of a single book... question: do you want to investigate this problem further or should I just (try to) fix my local problem?

Edit: 140112784 bytes ~= 140mb - quite a lot for some listen history

Yeah this is most likely the issue.
Currently the listening sessions store far too much data and the plan is to refactor that.
I can see if in this next release I can split up the requests