NullPointerException when setting StateFlow value

[hakonschia]

Describe the bug

After upgrading from version 1.6.4 to 1.7.1 (we have since bumped to 1.7.2) we started seeing NullPointerException crashes when updating a StateFlow value. I am not able to reproduce this locally, we are only seeing this through Firebase reports.

This is happening on Android with org.jetbrains.kotlinx:kotlinx-coroutines-android. It's happening on many different devices and Android versions, so it isn't specific to one manufacturer/version.

Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.lang.Class.isInterface()' on a null object reference
       at java.lang.Class.isAssignableFrom(Class.java:589)
       at java.lang.Class.isInstance(Class.java:542)
       at java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.accessCheck(AtomicReferenceFieldUpdater.java:389)
       at java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.get(AtomicReferenceFieldUpdater.java:447)
       at kotlinx.coroutines.flow.StateFlowSlot.makePending(StateFlowSlot.java:59)
       at kotlinx.coroutines.flow.StateFlowImpl.updateState(StateFlow.kt:349)
       at kotlinx.coroutines.flow.StateFlowImpl.setValue(StateFlow.kt:316)

Provide a Reproducer

We have a lot of flows, and only one specific one is crashing. The only unique thing about the flow that is causing crashes is that it holds an Enum, but I don't know if that's causing it.

The StateFlow is nullable, but the value set on it after initialization is never null. The code below isn't our production code, but is how our code looks like

enum class SomeEnum {
    Apple,
    Orange
}

class Class {
    val flow: StateFlow<SomeEnum?> get() = _mutableFlow
    private val _mutableFlow: MutableStateFlow<SomeEnum?> = MutableStateFlow(null)
    
    fun updateValue(value: SomeEnum) {
        _mutableFlow.value = value
    }
}

[vlad-kasatkin]

Seeing the same crash occasionally after an upgrade to 1.7.1.

In our case the flow receives a kotlin object implementing a sealed class. The flow is updated from a dedicated dispatcher created out of Executors.newSingleThreadExecutor().

   private sealed class Status {
    data class WithSomeData(val someData: Map<String, String>) : Status()
    object NoData : Status()
    object Initial: Status()
  }

  private val status = MutableStateFlow<Status>(Initial)

  fun updateStateFlow(coroutineScope: Scope) { 
    coroutineScope.launch { 
        someOtherFlow 
         .onEach { status.emit(NoData) } // <= Crashes on this line
         .flowOn(Executors.newSingleThreadExecutor().asCoroutineDispatcher())
         .collect()
    }
  }

java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.lang.Class.isInterface()' on a null object reference
        at java.lang.Class.isAssignableFrom(Class.java:589)
        at java.lang.Class.isInstance(Class.java:542)
        at java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.accessCheck(AtomicReferenceFieldUpdater.java:421)
        at java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.get(AtomicReferenceFieldUpdater.java:479)
        at kotlinx.coroutines.flow.StateFlowSlot.makePending(Unknown:2)
        at kotlinx.coroutines.flow.StateFlowImpl.updateState(StateFlow.kt:349)
        at kotlinx.coroutines.flow.StateFlowImpl.setValue(StateFlow.kt:316)
        at kotlinx.coroutines.flow.StateFlowImpl.emit(StateFlow.kt:373)

The same stateflow is updated with WithSomeData in another code-path, but from the main thread, and that code-path has not been seen in the stacktraces.

[vlad-kasatkin]

The last change to StateFlow.kt was in this PR: #3686. Which would have been a 1.7.0 release. We also went from 1.6.4, so the issue was likely in 1.70 originally, unless that PR is not related.

[mshdabiola]

Same exceptions when I upgrade to 1.7.2

Fatal Exception: java.lang.NullPointerException:
at kotlinx.coroutines.flow.FlowKt__ChannelsKt.access$emitAllImpl$FlowKt__ChannelsKt(FlowKt__Channels.kt:12)
at kotlinx.coroutines.flow.FlowKt__ChannelsKt$emitAllImpl$1.invokeSuspend(Channels.kt:12)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:1)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:1)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:92)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:92)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:92)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:92)

[vlad-kasatkin]

@mshdabiola This does not look the same at all, did you mean to paste a different trace?

[vlad-kasatkin]

We have received another instance of this crash updating ANOTHER stateflow, this time it's much simpler, but still being run on the background thread, IO dispatcher pool in this case.

class MyServiceClass(private val originStateFlow: StateFlow<Boolean>) {
    val ioContext = Dispatchers.IO

    val stateFlowToUpdate = MutableStateFlow(false)
    val coroutineScope = CoroutineScope(ioContext)

    fun updateFlow()
       coroutineScope.launch {
          originStateFlow
            .onEach(stateFlowToUpdate::value::set)
            .collect()
        }
    }
}

This instance of the crash is much more infrequent than the one I originally reported (that one has picking up in occurrences lately), but we have detailed analytics on how often this new crash code-path triggers. Out of 22_789_644 invocations it has triggered once, but this suggests to me that the issue is more widespread and can affect even simpler cases.

Full stacktrace with more details about how the stateflow is updated.

Crash occured on the first and only update to StateFlow, there were no other updates.

java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.lang.Class.isInterface()' on a null object reference
        at java.lang.Class.isAssignableFrom(Class.java:589)
        at java.lang.Class.isInstance(Class.java:542)
        at java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.accessCheck(AtomicReferenceFieldUpdater.java:421)
        at java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.get(AtomicReferenceFieldUpdater.java:479)
        at kotlinx.coroutines.flow.StateFlowSlot.makePending(Unknown:2)
        at kotlinx.coroutines.flow.StateFlowImpl.updateState(StateFlow.kt:349)
        at kotlinx.coroutines.flow.StateFlowImpl.setValue(StateFlow.kt:316)
        at com.example.package.MyServiceClass$updateFlow$2$2.set(MyServiceClass:55)
        at com.example.package.MyServiceClass$updateFlow$2.invokeSuspend$set(MyServiceClass:55)
        at com.example.package.MyServiceClass$updateFlow$2.access$invokeSuspend$set(Unknown)
        at com.example.package.MyServiceClass$updateFlow$2$1.invoke(MyServiceClass:55)
        at com.example.package.MyServiceClass$updateFlow$2$1.invoke(MyServiceClass:55)
        at com.example.package.MyServiceClass$updateFlow$2$1.invoke(MyServiceClass:55)
        at com.example.package.MyServiceClass$updateFlow$2$1.invoke(MyServiceClass:55)
        at kotlinx.coroutines.flow.FlowKt__TransformKt$onEach$$inlined$unsafeTransform$1$2.emit(Emitters.kt:223)
        at com.squareup.coroutines.util.MapStateFlowKt$mapStateFlow$1$collect$2.emit(MapStateFlow.kt:46)
        at kotlinx.coroutines.flow.StateFlowImpl.collect(StateFlow.kt:396)
        at com.squareup.coroutines.util.MapStateFlowKt$mapStateFlow$1.collect(MapStateFlow.kt:42)
        at kotlinx.coroutines.flow.FlowKt__TransformKt$onEach$$inlined$unsafeTransform$1.collect(SafeCollector.common.kt:113)
        at kotlinx.coroutines.flow.FlowKt__CollectKt.collect(Collect.kt:30)
        at kotlinx.coroutines.flow.FlowKt.collect(FlowKt:1)
        at com.example.package.MyServiceClass$updateFlow$2.invokeSuspend(MyServiceClass:56)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
        at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115)
        at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:100)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)

I have been trying to reproduce with the simplified version (this new crash), but it's still very hard to hit the exact race here. Does this ring any bell at all @qwwdfsad?

[vlad-kasatkin]

1.7.0 is also the version that included a bump of atomicfu from 0.17.3 to 0.20.2 that is a more likely culprit here

[hakonschia]

This has happened on another StateFlow now that holds a nullable data class

[vlad-kasatkin]

@hakonschia All our crashes are occurring when the MutableStateFlow is updated from the background thread close to the process instantiation. Are you seeing a similar pattern?

[hakonschia]

The original crash is happening on the main thread, and shouldn't be very close to process instantiation. The second is called from the IO dispatcher, but I don't think this should be close to process instantation either. The second is also a lot rarer, only happening 3 times compared to 80 for the original

[vlad-kasatkin]

We have now surpassed 100 crashes. A few additional details:

• It's always Android 13 and Android 12 that are crashing.
• It's not manufacturer specific - we see a wide range of devices and manufacturers.
• Seems to be rare enough for the same user to not crash more than once ever, however this crash is one of our top crashes now.

[hakonschia]

It's always Android 13 and Android 12 that are crashing.

We are also seeing this on Android 11, but not on lower versions

Seems to be rare enough for the same user to not crash more than once ever

We have some seen some repeats, but for the most part it has only happened once per user (100 crashes for 98 users)

Our crashes are mostly on Android TV and lower end phones/tablets

[vlad-kasatkin]

Got a few reports from the the 3rd party library as well:

java.lang.NullPointerException: Attempt to invoke virtual method ‘boolean java.lang.Class.isInterface()’ on a null object reference
        at java.lang.Class.isAssignableFrom(Class.java:589)
        at java.lang.Class.isInstance(Class.java:542)
        at java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.accessCheck(AtomicReferenceFieldUpdater.java:389)
        at java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.get(AtomicReferenceFieldUpdater.java:447)
        at kotlinx.coroutines.flow.StateFlowSlot.makePending(StateFlowSlot:59)
        at kotlinx.coroutines.flow.StateFlowImpl.updateState(StateFlowImpl:349)
        at kotlinx.coroutines.flow.StateFlowImpl.setValue(StateFlowImpl:316)
        at kotlinx.coroutines.flow.StateFlowImpl.emit(StateFlowImpl:373)
        at app.cash.sqldelight.coroutines.FlowQuery$mapToList$$inlined$map$1$2.emit(FlowQuery:223)
        at app.cash.sqldelight.coroutines.FlowQuery$mapToList$$inlined$map$1$2.emit$bridge(FlowQuery:181)
        at kotlinx.coroutines.flow.internal.SafeCollectorKt$emitFun$1.invoke(SafeCollectorKt:15)
        at kotlinx.coroutines.flow.internal.SafeCollectorKt$emitFun$1.invoke(SafeCollectorKt:15)
        at kotlinx.coroutines.flow.internal.SafeCollector.emit(SafeCollector:87)
        at kotlinx.coroutines.flow.internal.SafeCollector.emit(SafeCollector:66)
        at app.cash.sqldelight.coroutines.FlowQuery$asFlow$1.invokeSuspend(FlowQuery:48)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(BaseContinuationImpl:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask:108)
        at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher:115)
        at com.google.mlkit.common.sdkinternal.zza.run$bridge(zza:139)
        at kotlinx.coroutines.scheduling.TaskImpl.run(TaskImpl:103)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler:584)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler:793)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler:697)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler:684)

[qwwdfsad]

It seems like a long-standing bug in Android 12/13, as the quick search of Attempt to invoke virtual method 'boolean java.lang.Class.isInterface()' on a null object reference shows that a whole plethora of API is the subject to this bug.

It seems to be a bug on the edge of the DEX compiler, optimizer and specific runtime, which is almost impossible to reason about without a reproducer and access to the actual ART sources.

The only change in atomicfu I see that might have affected the reproducibility of the bug is modifiers on the corresponding field updater.

In 1.6.4 it was static final, but starting from 1.7.0 it's more precise: it's synthetic private static final; probably private is what triggers more aggressive optimizations, but I have no means to verify this hypothesis.