Infeasible
Status Update
No update yet.
Comments
mm...@gmail.com
This isn't fixed in alpha 6 :(. It's easily reproducible by starting a drag with one finger and then tapping somewhere else (think back button) which calls clearSelection().
ma...@google.com
mm...@gmail.com
Fix is in the works. Until then, a workaround is to avoid calling SelectionTracker#clearSelection while a gesture or mouse-band selection operation is in progress. Such a condition is likely not reflective of user intent (given the ongoing stream of selection operation), but reflective of a stray tap.
State can be monitored using OperationMonitor:
https://developer.android.com/reference/androidx/recyclerview/selection/OperationMonitor.OnChangeListener.html
State can be monitored using OperationMonitor:
ma...@google.com
BTW, working on a fix for this (general improvement to state management). My unassigning this issue from me should not be construed as lack of attention to the matter. I just manage issues by hotlist (rather than ownership).
ma...@google.com
Rolling all state-related crash reports up into a single tracking bug.
co...@gmail.com
Fixed in upcoming beta01 release.
co...@gmail.com
To describe what's happening in the sample, clicking the button adds a chunk of elements to the ListAdapter but also modifies an existing element. The real-world use case is a list of category headers which expand when clicked. After applying the two changes to the adapter, the DiffUtil is creating two ops of [ADD, UPDATE]. The ADD operation modifies mFullSpanItems.mPosition to be something like [1, 2, 3, 4, 5, 11, 12, 13, 14]. The op also tries to ensure that mData is large enough but instead does nothing. The UPDATE op then does an array copy by utilizing the mPosition values from the previous op. These mPosition values are outside the bounds of the array.
co...@gmail.com
This issue seems relevant but was marked fixed - probably because it's hard to reproduce.
https://issuetracker.google.com/issues/37086625
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 49b601979ebccb8fcc6b8d670b79ae1c5f818dbf
Author: Kolin Krewinkel <kkrewink@fb.com>
Date: Mon Jun 29 19:47:11 2020
[StaggeredGridLayoutManager] Avoid OutOfBounds exception during mutations if SpanLookup data structure has not yet been lengthened
**Background**
A use case within our app ran into this issue frequently as a result of inserting items between a set of full span items. We applied numerous band-aids (clearing of the span cache, filler items, etc.), but those had a bunch of unintended side-effects.
- Within the code, my first approach was to limit the array fill to `MIN(length, position)`, but that really didn't feel like the right fix.
- Digging deeper, I found that the position being extended to with `ensureSize()` did not factor in the maximum extent of items in `mData` or `mFullSpanItems` (which do not necessarily have the same "cap" in terms of position / length).
- A fix that I tried relating to this was to always `ensureSize()` for mData's length, but that results in expontential growth because of the fact that mData's length ≠ number of items.
- To keep it simple, I realized the easiest thing to do is just ensure that mData is large enough for the `item count` we're supposed to be displaying.
- Through discussion in review, we ended up reverting to the simpler version using `MIN()`.
Note that the test case does something which I *think* is pretty uncommon in vanilla adapters, but is the case for us when using it paired with Litho. That was the easiest repro case for me to arrive at, but I'm sure there are others.
Bug:122303625
Bug:74877618
Bug:160193663
Bug:37086625
Test: New test case in StaggeredGridLayoutManagerTest validates that the `Arrays.fill()` invocation does not lead to a crash.
Change-Id: Iab0a1220b4eae8f2b184822d518c6d696c278b19
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/StaggeredGridLayoutManagerTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/StaggeredGridLayoutManager.java
https://android-review.googlesource.com/1354704
Branch: androidx-master-dev
commit 49b601979ebccb8fcc6b8d670b79ae1c5f818dbf
Author: Kolin Krewinkel <kkrewink@fb.com>
Date: Mon Jun 29 19:47:11 2020
[StaggeredGridLayoutManager] Avoid OutOfBounds exception during mutations if SpanLookup data structure has not yet been lengthened
**Background**
A use case within our app ran into this issue frequently as a result of inserting items between a set of full span items. We applied numerous band-aids (clearing of the span cache, filler items, etc.), but those had a bunch of unintended side-effects.
- Within the code, my first approach was to limit the array fill to `MIN(length, position)`, but that really didn't feel like the right fix.
- Digging deeper, I found that the position being extended to with `ensureSize()` did not factor in the maximum extent of items in `mData` or `mFullSpanItems` (which do not necessarily have the same "cap" in terms of position / length).
- A fix that I tried relating to this was to always `ensureSize()` for mData's length, but that results in expontential growth because of the fact that mData's length ≠ number of items.
- To keep it simple, I realized the easiest thing to do is just ensure that mData is large enough for the `item count` we're supposed to be displaying.
- Through discussion in review, we ended up reverting to the simpler version using `MIN()`.
Note that the test case does something which I *think* is pretty uncommon in vanilla adapters, but is the case for us when using it paired with Litho. That was the easiest repro case for me to arrive at, but I'm sure there are others.
Bug:122303625
Bug:74877618
Bug:160193663
Bug:37086625
Test: New test case in StaggeredGridLayoutManagerTest validates that the `Arrays.fill()` invocation does not lead to a crash.
Change-Id: Iab0a1220b4eae8f2b184822d518c6d696c278b19
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/StaggeredGridLayoutManagerTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/StaggeredGridLayoutManager.java
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 49b601979ebccb8fcc6b8d670b79ae1c5f818dbf
Author: Kolin Krewinkel <kkrewink@fb.com>
Date: Mon Jun 29 19:47:11 2020
[StaggeredGridLayoutManager] Avoid OutOfBounds exception during mutations if SpanLookup data structure has not yet been lengthened
**Background**
A use case within our app ran into this issue frequently as a result of inserting items between a set of full span items. We applied numerous band-aids (clearing of the span cache, filler items, etc.), but those had a bunch of unintended side-effects.
- Within the code, my first approach was to limit the array fill to `MIN(length, position)`, but that really didn't feel like the right fix.
- Digging deeper, I found that the position being extended to with `ensureSize()` did not factor in the maximum extent of items in `mData` or `mFullSpanItems` (which do not necessarily have the same "cap" in terms of position / length).
- A fix that I tried relating to this was to always `ensureSize()` for mData's length, but that results in expontential growth because of the fact that mData's length ≠ number of items.
- To keep it simple, I realized the easiest thing to do is just ensure that mData is large enough for the `item count` we're supposed to be displaying.
- Through discussion in review, we ended up reverting to the simpler version using `MIN()`.
Note that the test case does something which I *think* is pretty uncommon in vanilla adapters, but is the case for us when using it paired with Litho. That was the easiest repro case for me to arrive at, but I'm sure there are others.
Bug:122303625
Bug:74877618
Bug:160193663
Bug:37086625
Test: New test case in StaggeredGridLayoutManagerTest validates that the `Arrays.fill()` invocation does not lead to a crash.
Change-Id: Iab0a1220b4eae8f2b184822d518c6d696c278b19
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/StaggeredGridLayoutManagerTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/StaggeredGridLayoutManager.java
https://android-review.googlesource.com/1354704
Branch: androidx-master-dev
commit 49b601979ebccb8fcc6b8d670b79ae1c5f818dbf
Author: Kolin Krewinkel <kkrewink@fb.com>
Date: Mon Jun 29 19:47:11 2020
[StaggeredGridLayoutManager] Avoid OutOfBounds exception during mutations if SpanLookup data structure has not yet been lengthened
**Background**
A use case within our app ran into this issue frequently as a result of inserting items between a set of full span items. We applied numerous band-aids (clearing of the span cache, filler items, etc.), but those had a bunch of unintended side-effects.
- Within the code, my first approach was to limit the array fill to `MIN(length, position)`, but that really didn't feel like the right fix.
- Digging deeper, I found that the position being extended to with `ensureSize()` did not factor in the maximum extent of items in `mData` or `mFullSpanItems` (which do not necessarily have the same "cap" in terms of position / length).
- A fix that I tried relating to this was to always `ensureSize()` for mData's length, but that results in expontential growth because of the fact that mData's length ≠ number of items.
- To keep it simple, I realized the easiest thing to do is just ensure that mData is large enough for the `item count` we're supposed to be displaying.
- Through discussion in review, we ended up reverting to the simpler version using `MIN()`.
Note that the test case does something which I *think* is pretty uncommon in vanilla adapters, but is the case for us when using it paired with Litho. That was the easiest repro case for me to arrive at, but I'm sure there are others.
Bug:122303625
Bug:74877618
Bug:160193663
Bug:37086625
Test: New test case in StaggeredGridLayoutManagerTest validates that the `Arrays.fill()` invocation does not lead to a crash.
Change-Id: Iab0a1220b4eae8f2b184822d518c6d696c278b19
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/StaggeredGridLayoutManagerTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/StaggeredGridLayoutManager.java
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 49b601979ebccb8fcc6b8d670b79ae1c5f818dbf
Author: Kolin Krewinkel <kkrewink@fb.com>
Date: Mon Jun 29 19:47:11 2020
[StaggeredGridLayoutManager] Avoid OutOfBounds exception during mutations if SpanLookup data structure has not yet been lengthened
**Background**
A use case within our app ran into this issue frequently as a result of inserting items between a set of full span items. We applied numerous band-aids (clearing of the span cache, filler items, etc.), but those had a bunch of unintended side-effects.
- Within the code, my first approach was to limit the array fill to `MIN(length, position)`, but that really didn't feel like the right fix.
- Digging deeper, I found that the position being extended to with `ensureSize()` did not factor in the maximum extent of items in `mData` or `mFullSpanItems` (which do not necessarily have the same "cap" in terms of position / length).
- A fix that I tried relating to this was to always `ensureSize()` for mData's length, but that results in expontential growth because of the fact that mData's length ≠ number of items.
- To keep it simple, I realized the easiest thing to do is just ensure that mData is large enough for the `item count` we're supposed to be displaying.
- Through discussion in review, we ended up reverting to the simpler version using `MIN()`.
Note that the test case does something which I *think* is pretty uncommon in vanilla adapters, but is the case for us when using it paired with Litho. That was the easiest repro case for me to arrive at, but I'm sure there are others.
Bug:122303625
Bug:74877618
Bug:160193663
Bug:37086625
Test: New test case in StaggeredGridLayoutManagerTest validates that the `Arrays.fill()` invocation does not lead to a crash.
Change-Id: Iab0a1220b4eae8f2b184822d518c6d696c278b19
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/StaggeredGridLayoutManagerTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/StaggeredGridLayoutManager.java
https://android-review.googlesource.com/1354704
Branch: androidx-master-dev
commit 49b601979ebccb8fcc6b8d670b79ae1c5f818dbf
Author: Kolin Krewinkel <kkrewink@fb.com>
Date: Mon Jun 29 19:47:11 2020
[StaggeredGridLayoutManager] Avoid OutOfBounds exception during mutations if SpanLookup data structure has not yet been lengthened
**Background**
A use case within our app ran into this issue frequently as a result of inserting items between a set of full span items. We applied numerous band-aids (clearing of the span cache, filler items, etc.), but those had a bunch of unintended side-effects.
- Within the code, my first approach was to limit the array fill to `MIN(length, position)`, but that really didn't feel like the right fix.
- Digging deeper, I found that the position being extended to with `ensureSize()` did not factor in the maximum extent of items in `mData` or `mFullSpanItems` (which do not necessarily have the same "cap" in terms of position / length).
- A fix that I tried relating to this was to always `ensureSize()` for mData's length, but that results in expontential growth because of the fact that mData's length ≠ number of items.
- To keep it simple, I realized the easiest thing to do is just ensure that mData is large enough for the `item count` we're supposed to be displaying.
- Through discussion in review, we ended up reverting to the simpler version using `MIN()`.
Note that the test case does something which I *think* is pretty uncommon in vanilla adapters, but is the case for us when using it paired with Litho. That was the easiest repro case for me to arrive at, but I'm sure there are others.
Bug:122303625
Bug:74877618
Bug:160193663
Bug:37086625
Test: New test case in StaggeredGridLayoutManagerTest validates that the `Arrays.fill()` invocation does not lead to a crash.
Change-Id: Iab0a1220b4eae8f2b184822d518c6d696c278b19
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/StaggeredGridLayoutManagerTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/StaggeredGridLayoutManager.java
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 49b601979ebccb8fcc6b8d670b79ae1c5f818dbf
Author: Kolin Krewinkel <kkrewink@fb.com>
Date: Mon Jun 29 19:47:11 2020
[StaggeredGridLayoutManager] Avoid OutOfBounds exception during mutations if SpanLookup data structure has not yet been lengthened
**Background**
A use case within our app ran into this issue frequently as a result of inserting items between a set of full span items. We applied numerous band-aids (clearing of the span cache, filler items, etc.), but those had a bunch of unintended side-effects.
- Within the code, my first approach was to limit the array fill to `MIN(length, position)`, but that really didn't feel like the right fix.
- Digging deeper, I found that the position being extended to with `ensureSize()` did not factor in the maximum extent of items in `mData` or `mFullSpanItems` (which do not necessarily have the same "cap" in terms of position / length).
- A fix that I tried relating to this was to always `ensureSize()` for mData's length, but that results in expontential growth because of the fact that mData's length ≠ number of items.
- To keep it simple, I realized the easiest thing to do is just ensure that mData is large enough for the `item count` we're supposed to be displaying.
- Through discussion in review, we ended up reverting to the simpler version using `MIN()`.
Note that the test case does something which I *think* is pretty uncommon in vanilla adapters, but is the case for us when using it paired with Litho. That was the easiest repro case for me to arrive at, but I'm sure there are others.
Bug:122303625
Bug:74877618
Bug:160193663
Bug:37086625
Test: New test case in StaggeredGridLayoutManagerTest validates that the `Arrays.fill()` invocation does not lead to a crash.
Change-Id: Iab0a1220b4eae8f2b184822d518c6d696c278b19
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/StaggeredGridLayoutManagerTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/StaggeredGridLayoutManager.java
https://android-review.googlesource.com/1354704
Branch: androidx-master-dev
commit 49b601979ebccb8fcc6b8d670b79ae1c5f818dbf
Author: Kolin Krewinkel <kkrewink@fb.com>
Date: Mon Jun 29 19:47:11 2020
[StaggeredGridLayoutManager] Avoid OutOfBounds exception during mutations if SpanLookup data structure has not yet been lengthened
**Background**
A use case within our app ran into this issue frequently as a result of inserting items between a set of full span items. We applied numerous band-aids (clearing of the span cache, filler items, etc.), but those had a bunch of unintended side-effects.
- Within the code, my first approach was to limit the array fill to `MIN(length, position)`, but that really didn't feel like the right fix.
- Digging deeper, I found that the position being extended to with `ensureSize()` did not factor in the maximum extent of items in `mData` or `mFullSpanItems` (which do not necessarily have the same "cap" in terms of position / length).
- A fix that I tried relating to this was to always `ensureSize()` for mData's length, but that results in expontential growth because of the fact that mData's length ≠ number of items.
- To keep it simple, I realized the easiest thing to do is just ensure that mData is large enough for the `item count` we're supposed to be displaying.
- Through discussion in review, we ended up reverting to the simpler version using `MIN()`.
Note that the test case does something which I *think* is pretty uncommon in vanilla adapters, but is the case for us when using it paired with Litho. That was the easiest repro case for me to arrive at, but I'm sure there are others.
Bug:122303625
Bug:74877618
Bug:160193663
Bug:37086625
Test: New test case in StaggeredGridLayoutManagerTest validates that the `Arrays.fill()` invocation does not lead to a crash.
Change-Id: Iab0a1220b4eae8f2b184822d518c6d696c278b19
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/StaggeredGridLayoutManagerTest.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/StaggeredGridLayoutManager.java
Description
Version used: 27.1.0
Theme used: Theme.AppCompat.Light.NoActionBar
Devices/Android versions reproduced on: Nexus 6, API 27
StaggeredGridLayoutManager.LazySpanLookup.invalidateAfter(position) doesn't check condition (position == RecyclerView.NO_POSITION) thus causing the call to Array.fill(...) to throw an ArrayIndexOutOfBoundsException since the array start position (which is position = NO_POSITION = -1) is less than 0. Unfortunately, I haven't managed to reproduce the issue reliably to get into this state to begin with.
Stacktrace:
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: -1
at java.util.Arrays.rangeCheck(Arrays.java:120)
at java.util.Arrays.fill(Arrays.java:2831)
at android.support.v7.widget.StaggeredGridLayoutManager$LazySpanLookup.invalidateAfter(StaggeredGridLayoutManager.java:2876)
at android.support.v7.widget.StaggeredGridLayoutManager.handleUpdate(StaggeredGridLayoutManager.java:1552)
at android.support.v7.widget.StaggeredGridLayoutManager.onItemsUpdated(StaggeredGridLayoutManager.java:1528)
at android.support.v7.widget.RecyclerView$6.dispatchUpdate(RecyclerView.java:943)
at android.support.v7.widget.RecyclerView$6.onDispatchFirstPass(RecyclerView.java:931)
at android.support.v7.widget.AdapterHelper.dispatchFirstPassAndUpdateViewHolders(AdapterHelper.java:314)
at android.support.v7.widget.AdapterHelper.dispatchAndUpdateViewHolders(AdapterHelper.java:300)
at android.support.v7.widget.AdapterHelper.applyUpdate(AdapterHelper.java:220)
at android.support.v7.widget.AdapterHelper.preProcess(AdapterHelper.java:104)
at android.support.v7.widget.RecyclerView.processAdapterUpdatesAndSetAnimationFlags(RecyclerView.java:3471)
at android.support.v7.widget.RecyclerView.dispatchLayoutStep1(RecyclerView.java:3717)
at android.support.v7.widget.RecyclerView.dispatchLayout(RecyclerView.java:3527)
at android.support.v7.widget.RecyclerView.consumePendingUpdateOperations(RecyclerView.java:1767)
at android.support.v7.widget.RecyclerView$ViewFlinger.run(RecyclerView.java:4928)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:911)
at android.view.Choreographer.doCallbacks(Choreographer.java:723)
at android.view.Choreographer.doFrame(Choreographer.java:655)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:897)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6494)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:440)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)