Fixed
Status Update
No update yet.
Comments
ar...@gmail.com
Hello,
may I ask if this ticket is in work?
I came here the last 8 days and nothing has happened. I do not want to encumber, I'm just curious.
Have a nice weekend.
Yours sincerely,
David Artmann
may I ask if this ticket is in work?
I came here the last 8 days and nothing has happened. I do not want to encumber, I'm just curious.
Have a nice weekend.
Yours sincerely,
David Artmann
am...@google.com
am...@google.com
Hi,
Can you please provide below information
Which support library did you use?
Please provide compile-able sample project on android studio, the one you have shared here is not compatible to compile on studio. So please share the proper one.
Also there is a similar issue for support library 22.0.0
https://code.google.com/p/android/issues/detail?id=161464 .Please let me know if you are also using the same one.
Can you please provide below information
Which support library did you use?
Please provide compile-able sample project on android studio, the one you have shared here is not compatible to compile on studio. So please share the proper one.
Also there is a similar issue for support library 22.0.0
ar...@gmail.com
Hi,
I'm using support lib v23.2.0
(The error also happens in the older v23.1.1, which I used before -> I did not use version 22.0.0 in my project)
Also I attached the (hopefully) compile-able version of my project.
Yours sincerely,
David
I'm using support lib v23.2.0
(The error also happens in the older v23.1.1, which I used before -> I did not use version 22.0.0 in my project)
Also I attached the (hopefully) compile-able version of my project.
Yours sincerely,
David
am...@google.com
Could you please provide more clarity on expected and observed behavior along with the screenshots.
Let me know how to use your app to reproduce the issue
Also check it once with the latest support lib 24.2.1 and let me know if issue persists
Let me know how to use your app to reproduce the issue
Also check it once with the latest support lib 24.2.1 and let me know if issue persists
ar...@gmail.com
With latest support lib (25.0.0), the problem did not appear any more. Also with previous (24.2.1). Thanky you.
am...@google.com
Thanks for the update.
co...@gmail.com
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
I'm doing this the first time, so please have merci ;)
I am using a StaggeredGridLayoutManager in my RecyclerView inside of a Fragment.
While performing a search over a list the vizualisation works as it should and items are getting removed and added.
But after filtering all elements of the list out so the view is empty and then removing the additional letter so the previous items should be seeable again, an ArrayIndexOutOfBoundsException is thrown at java.util.Arrays.checkStartAndEnd(Arrays.java:1732) with the message "start < 0 || end > len. start=-1, end=11, len=11".
I added the output of "adb bugreport" and added also the main folder of my project, so you can hopefully understand what I am talking about and reporoduce the error.
The Exception is happening on all devices I could use to test, inclusive the emulator (I only had Devices with API lvl 22 & 23).
If you need any further informations I will provide them.
Also I hope that this is a real Bug and not caused by my own stupidity.
Yours sincerely,
David Artmann