Paging 3 crash if PagingSource is invalidated while RecycleView is scrolling [347649763]

Duplicate

of 343124454

Bug

Status Update

No update yet.

Description

ni...@gmail.com

created issue #1

Jun 17, 2024 12:49PM

Hi, I have been struggling with this for some time and finally decided to post there to make sure it is not me doing something wrong.

Please see attached POC, screen recording and sample crash log in the attached file. Project is created with Android Studio Koala Feature Drop | 2024.1.2 Canary 5

Issue:

Attached project demonstrates crash with a Room database but I use custom PagingSource because I also use Paging 3 with content providers such as call log and contacts.

Due to my my project's needs, I need to invalidate PagingSource from outside every now and then. One of the reasons for that is inserting adverts to certain locations.

I created Invalidator interface which InvalidatingPagingSource that extends PagingSource uses. InvalidatingPagingSource in return extended by my custom paging source and ViewModel is provided with an instance of Invalidator so it can call Invalidator.invalidateNow() when it needs to invalidate the paging source.

This setup works fine when data is on screen and no scrolling is being done. However, if invalidation happens while user is scrolling app crashes with

java.lang.IndexOutOfBoundsException: Inconsistency detected. Invalid item position 115(offset:115).state:207 androidx.recyclerview.widget.RecyclerView{fdd315c VFED.V... ......ID 48,48-1296,2800 #7f080143 app:id/notesRecycler}, adapter:com.example.paging3.NotesAdapterPaging@52fd8c2, layout:androidx.recyclerview.widget.LinearLayoutManager@17696d3, context:com.example.paging3.MainActivity@1d73791
at androidx.recyclerview.widget.RecyclerView$Recycler.tryGetViewHolderForPositionByDeadline(RecyclerView.java:6364)
at androidx.recyclerview.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:6300)
at androidx.recyclerview.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:6296)
at androidx.recyclerview.widget.LinearLayoutManager$LayoutState.next(LinearLayoutManager.java:2330)
at androidx.recyclerview.widget.LinearLayoutManager.layoutChunk(LinearLayoutManager.java:1631)
at androidx.recyclerview.widget.LinearLayoutManager.fill(LinearLayoutManager.java:1591)
at androidx.recyclerview.widget.LinearLayoutManager.scrollBy(LinearLayoutManager.java:1395)
at androidx.recyclerview.widget.LinearLayoutManager.scrollVerticallyBy(LinearLayoutManager.java:1136)
at androidx.recyclerview.widget.RecyclerView.scrollStep(RecyclerView.java:1972)
at androidx.recyclerview.widget.RecyclerView$ViewFlinger.run(RecyclerView.java:5476)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1339)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1348)
at android.view.Choreographer.doCallbacks(Choreographer.java:952)
at android.view.Choreographer.doFrame(Choreographer.java:878)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1322)
at android.os.Handler.handleCallback(Handler.java:958)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at android.app.ActivityThread.main(ActivityThread.java:8177)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:971)

I am not sure if I am being thick but, when I check the source of tryGetViewHolderForPositionByDeadline I see that it does these checks:

if (position < 0 || position >= mState.getItemCount()) {    
throw new IndexOutOfBoundsException("Invalid item position " + position    
+ "(" + position + "). Item count:" + mState.getItemCount()
+ exceptionLabel()); 
}

According to log however, position 115(offset:115) falls in to state:207 so crash should not happen. What am I missing?

Notes:

Please be patient after first lunch as app creates 5K sample notes.
You may need to scroll fast a couple of times to create the crash.

poc.zip

1.4 MB

Download

Comments

ba...@gmail.com <ba...@gmail.com> #2Jun 18, 2024 05:42AM

Yigit, do you have time to fix it?

reemission of the same liveData is racy

ni...@gmail.com <ni...@gmail.com> #3Jun 18, 2024 07:34AM

yea i'll take it.

ba...@gmail.com <ba...@gmail.com> #4Jun 19, 2024 02:03PM

Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.

ni...@gmail.com <ni...@gmail.com> #5Jun 19, 2024 02:36PM

just emitting same live data reproduces the issue.

@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}

lo...@gmail.com <lo...@gmail.com> #6Jun 23, 2024 11:53AM

With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)

lo...@gmail.com <lo...@gmail.com> #7Jun 23, 2024 11:55AM

yea sorry immediate does not fix it.
I actually have a WIP fix for it:

https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186

if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.

val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}

cl...@google.com <cl...@google.com> Jun 26, 2024 10:56PM

Status: Duplicate of

343124454