Potential Race Condition in CrashManager leading to IndexOutOfBoundsException or NPE

[RSM-CZE]

We are observing rare crashes in our application that appear to be caused by a race condition within the CrashManager.

Our application's architecture involves stopping and re-starting the Exponea SDK integration at runtime.

I can see a possible scenario where
CrashManager.saveLogMessage
is running, while the SDK clears the list in
CrashManger.onIntegrationStopped

With that assumption, the internal state of the LinkedList becomes inconsistent, leading to a crash.

Observed Crashes

We have observed two types of fatal exceptions:

• IndexOutOfBoundsException when the list is cleared and then removeAt is invoked

       Fatal Exception: java.lang.IndexOutOfBoundsException: Index: 0, Size: -1
       at java.util.LinkedList.checkPositionIndex(LinkedList.java:561)
       at java.util.LinkedList.add(LinkedList.java:508)
       at com.exponea.sdk.telemetry.CrashManager.saveLogMessage(CrashManager.kt:78)
       at com.exponea.sdk.telemetry.TelemetryManager.reportLog(TelemetryManager.kt:105)
       at com.exponea.sdk.telemetry.TelemetryManager.reportLog$default(TelemetryManager.kt:100)
       at com.exponea.sdk.util.Logger.d(Logger.kt:52)
       at com.exponea.sdk.manager.FetchManagerImpl.parseRawResponse(FetchManagerImpl.kt:91)
       at com.exponea.sdk.manager.FetchManagerImpl.parseStandardResult(FetchManagerImpl.kt:111)
       at com.exponea.sdk.manager.FetchManagerImpl.access$parseStandardResult(FetchManagerImpl.kt:28)
       at com.exponea.sdk.manager.FetchManagerImpl$getStandardFetchCallback$1.onResponse(FetchManagerImpl.kt:44)
       at com.google.firebase.perf.network.InstrumentOkHttpEnqueueCallback.onResponse(InstrumentOkHttpEnqueueCallback.java:71)
       at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
       at java.util.concurrent.ThreadPoolExecutor.processTask(ThreadPoolExecutor.java:1187)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
       at java.lang.Thread.run(Thread.java:784)

• NullPointerException within the LinkedList's internal implementation, which also indicates concurrent modification:

       Fatal Exception: java.lang.NullPointerException: Attempt to read from field 'java.util.LinkedList$Node java.util.LinkedList$Node.prev' on a null object reference in method 'void java.util.LinkedList.linkBefore(java.lang.Object, java.util.LinkedList$Node)'
       at java.util.LinkedList.linkBefore(LinkedList.java:168)
       at java.util.LinkedList.add(LinkedList.java:523)
       at com.exponea.sdk.telemetry.CrashManager.saveLogMessage(CrashManager.kt:78)
       at com.exponea.sdk.telemetry.TelemetryManager.reportLog(TelemetryManager.kt:105)
       at com.exponea.sdk.telemetry.TelemetryManager.reportLog$default(TelemetryManager.kt:100)
       at com.exponea.sdk.util.Logger.d(Logger.kt:52)
       at com.exponea.sdk.manager.InAppMessageManagerImpl$reload$1.invoke(InAppMessageManagerImpl.kt:126)
       at com.exponea.sdk.manager.InAppMessageManagerImpl$reload$1.invoke(InAppMessageManagerImpl.kt:113)
       at com.exponea.sdk.manager.FetchManagerImpl$fetchInAppMessages$2.invoke(FetchManagerImpl.kt:202)
       at com.exponea.sdk.manager.FetchManagerImpl$fetchInAppMessages$2.invoke(FetchManagerImpl.kt:199)
       at com.exponea.sdk.manager.FetchManagerImpl$getStandardFetchCallback$1.onResponse(FetchManagerImpl.kt:46)
       at com.google.firebase.perf.network.InstrumentOkHttpEnqueueCallback.onResponse(InstrumentOkHttpEnqueueCallback.java:71)
       at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1154)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:652)
       at java.lang.Thread.run(Thread.java:1564)

Environment

Exponea SDK Version: 4.8.1
Android: observed on Android 9-16, should not matter for this issue

[brgarcar]

Hi @RSM-CZE, thank you for the detailed report and the clear stack traces.

You are correct. There is a race condition in CrashManager where saveLogMessage() and onIntegrationStopped() can concurrently access the same log buffer without proper synchronization.

We will let you know as soon as the new version with the fix is available.