epoxy: [epoxy-paging] Crash in the PagedListEpoxyController when trying to invoke `addTo` on a null model

While trying to implement paged list + paged controller, I run into a crash that’s not reliably reproducible. The crash seems to happen around 1 in 7 times, completely anecdotally.

I’m attaching the stack trace: note how my custom controller (that extends PagedListEpoxyController) is not in the stack trace because the crash happens in PagedListEpoxyController internals.

I will try to get a small sample app with a reliable reproducible test case. In the meantime, some information that could be useful:

  • In MyImplementationPagedListController, I have these two params:
    • modelBuildingHandler = EpoxyAsyncUtil.getAsyncBackgroundHandler()
    • diffingHandler = EpoxyAsyncUtil.getAsyncBackgroundHandler()
  • I’m using an RxPagedListBuilder with setFetchScheduler(Schedulers.io())
  • The problem reproduces more frequently with a very small page size: I used size 4 on a total list size 22

I noticed that PagedListModelCache holds null models, I am guessing one of those is likely mistakenly being passed through in getModels().

java.lang.NullPointerException: Attempt to invoke virtual method 'void com.airbnb.epoxy.EpoxyModel.addTo(com.airbnb.epoxy.EpoxyController)' on a null object reference
at com.airbnb.epoxy.EpoxyController.add(EpoxyController.java:465)
at com.airbnb.epoxy.paging.PagedListEpoxyController.addModels(PagedListEpoxyController.kt:78)
at com.airbnb.epoxy.paging.PagedListEpoxyController.buildModels(PagedListEpoxyController.kt:70)
at com.airbnb.epoxy.EpoxyController$1.run(EpoxyController.java:267)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.os.HandlerThread.run(HandlerThread.java:61)

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 23 (15 by maintainers)

Commits related to this issue

Most upvoted comments

@AdamMc331 That’s very likely as we only see crashes in controllers where we add additional models. However your proposed solution won’t work for us as the additional models we add can’t be delayed otherwise the screens get weird.

We are delaying the submitList instead. But this is just a band-aid. I’m not sure where to start to solve the race condition.

Yeah, that’s the reason why I made the attempt to use RxJava to check out whether it will crash or not after applying the hint from @rohandhruva . And it indeed turns out to be good.

Looks like this crash is not trivial to troubleshoot. May be the framework could fail-fast in case notify scheduler is not on the same thread than the model building ?