Fixed
Status Update
No update yet.
Comments
ar...@gmail.com
ar...@gmail.com
If the width or height is greater than 8191, left-shifting causes the sign bit to be lost, turning a '1' into a '0', which results in an incorrect width or height.
I agree there's a bug here, but I'm not sure this is quite a precise description of the problem. A quick experiment suggests that the left shift (<<) works fine (if we are just looking at bits), but the right shift (>>) is where the problem is introduced, because >> does "sign extension" in Java - meaning if input value is negative (the MSB of the 32-bit int is 1), then the result will be negative too. This can be fixed by using the unsigned right shift operator (>>>).
You can see this in jshell:
$ jshell
| Welcome to JShell -- Version 22
| For an introduction type: /help intro
jshell> int width = 5
width ==> 5
jshell> int height = 8192
height ==> 8192
jshell> int widthAndHeight = (width << 16) | height
widthAndHeight ==> 335872
jshell> (widthAndHeight << 18) >> 18
$8 ==> -8192
jshell> (widthAndHeight << 18) >>> 18
$9 ==> 8192
That said, I also agree that your change in
am...@google.com
ar...@gmail.com
Project: platform/frameworks/support
Branch: androidx-main
commit 59e5677498b92689c2c92801c1f371f24ca7024e
Author: Ian Baker <ibaker@google.com>
Date: Thu Aug 01 16:12:27 2024
Add a test WebP image with a height of 8192px
This exercises the bug reported inhttps://issuetracker.google.com/342697059
The test is disabled for now. It can be enabled as part of merging the
fix inhttps://github.com/androidx/androidx/pull/683 .
This image was generated using imagemagick:
$ convert webp_without_exif.webp \
-resize 6144x8192 \
webp_without_exif_height_8192px.webp
Bug: 342697059
Test: ExifInterfaceTest
Change-Id: Ib014f54fbe8d28579f95d5d2f34e302cdd569fb9
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
A exifinterface/exifinterface/src/androidTest/res/raw/webp_without_exif_height_8192px.webp
https://android-review.googlesource.com/3204431
Branch: androidx-main
commit 59e5677498b92689c2c92801c1f371f24ca7024e
Author: Ian Baker <ibaker@google.com>
Date: Thu Aug 01 16:12:27 2024
Add a test WebP image with a height of 8192px
This exercises the bug reported in
The test is disabled for now. It can be enabled as part of merging the
fix in
This image was generated using imagemagick:
$ convert webp_without_exif.webp \
-resize 6144x8192 \
webp_without_exif_height_8192px.webp
Bug: 342697059
Test: ExifInterfaceTest
Change-Id: Ib014f54fbe8d28579f95d5d2f34e302cdd569fb9
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
A exifinterface/exifinterface/src/androidTest/res/raw/webp_without_exif_height_8192px.webp
am...@google.com
am...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit e6f75a0d1eb7fe104812ffaa108b71ed7a86b2d4
Author: Ian Baker <ibaker@google.com>
Date: Tue Aug 06 13:59:45 2024
Add missing comment to @SdkSuppress annotation
This explains why this test is skipped on API 21.
Test: ExifInterfaceTest
Bug: 342697059
Change-Id: I49b364107f52827417540e87704010cbc8f5a02e
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
https://android-review.googlesource.com/3204518
Branch: androidx-main
commit e6f75a0d1eb7fe104812ffaa108b71ed7a86b2d4
Author: Ian Baker <ibaker@google.com>
Date: Tue Aug 06 13:59:45 2024
Add missing comment to @SdkSuppress annotation
This explains why this test is skipped on API 21.
Test: ExifInterfaceTest
Bug: 342697059
Change-Id: I49b364107f52827417540e87704010cbc8f5a02e
M exifinterface/exifinterface/src/androidTest/java/androidx/exifinterface/media/ExifInterfaceTest.java
ar...@gmail.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.exifinterface:exifinterface:1.4.0-alpha01
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