elishas
commented
1 year ago We couldn't find any memory leak. It might be that the OOM that you see is just the straw that broke the camel's back. Meaning that the app would get OOM even without Shipbook's it just got to the limit of the memory and then came the SDK and asked some more memory .
When I checked the call stack due to OOM, it seems to have started with the SBCloudAppender used by Shipbook as shown below. Please check.
java.lang.OutOfMemoryError: Failed to allocate a 150994952 byte allocation with 25165824 free bytes and 124MB until OOM, target footprint 163527000, growth limit 268435456 at java.util.Arrays.copyOf(Arrays.java:3766) at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:125) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:650) at java.lang.StringBuilder.append(StringBuilder.java:203) at org.json.JSONStringer.string(JSONStringer.java:354) at org.json.JSONStringer.value(JSONStringer.java:261) at org.json.JSONObject.writeTo(JSONObject.java:734) at org.json.JSONObject.toString(JSONObject.java:702) at java.lang.String.valueOf(String.java:3657) at java.lang.StringBuilder.append(StringBuilder.java:132) at jc.d.f(SBCloudAppender.kt:211) at jc.d$c.p(SBCloudAppender.kt:53) at xc.a.g(ContinuationImpl.kt:9) at rf.f0.run(DispatchedTask.kt:107) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:463) at java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:307) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637) at java.lang.Thread.run(Thread.java:1012) Suppressed: u6.i1: [g1{Cancelling}@fa3b1a6, java.util.concurrent.ScheduledThreadPoolExecutor@53767e7[Running, pool size = 1, active threads = 1, queued tasks = 2, completed tasks = 42]]