java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 1 (take 2) [375343407]

Fixed

Bug

Status Update

No update yet.

Description

si...@gmail.com

created issue #1

Oct 24, 2024 12:31PM

Component used: Activity

Versions used:

androidx.activity:activity-compose:1.9.3
androidx.activity:activity-ktx:1.9.3
androidx.navigation:navigation-compose:2.8.3

Devices/Android versions reproduced on: Pixel 7 API 35 (emulator)

Sample project: https://github.com/sindrenm/compose-navigation-crash-repro

This is a follow-up to 340202286, since #39 requested we open a new issue. I have a sample project (linked above) that reproduces the issue consistently by using the debugger, but we're also seeing this crash happen for our users (same stack trace) in production builds with the same library versions. Note that we have not been able to reproduce it locally without using the debugger, but our users are.

The stack trace is as follows:

FATAL EXCEPTION: main
Process: dev.sindrenm.repro.backnavigation, PID: 21646
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 1
  at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
  at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
  at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266)
  at java.util.Objects.checkIndex(Objects.java:359)
  at java.util.ArrayList.get(ArrayList.java:434)
  at androidx.navigation.compose.NavHostKt$NavHost$25$1.invokeSuspend(NavHost.kt:518)
  at androidx.navigation.compose.NavHostKt$NavHost$25$1.invoke(Unknown Source:8)
  at androidx.navigation.compose.NavHostKt$NavHost$25$1.invoke(Unknown Source:4)
  at androidx.activity.compose.OnBackInstance$job$1.invokeSuspend(PredictiveBackHandler.kt:121)
  at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
  at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
  at androidx.compose.ui.platform.AndroidUiDispatcher.performTrampolineDispatch(AndroidUiDispatcher.android.kt:81)
  at androidx.compose.ui.platform.AndroidUiDispatcher.access$performTrampolineDispatch(AndroidUiDispatcher.android.kt:41)
  at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.run(AndroidUiDispatcher.android.kt:57)
  at android.os.Handler.handleCallback(Handler.java:959)
  at android.os.Handler.dispatchMessage(Handler.java:100)
  at android.os.Looper.loopOnce(Looper.java:232)
  at android.os.Looper.loop(Looper.java:317)
  at android.app.ActivityThread.main(ActivityThread.java:8705)
  at java.lang.reflect.Method.invoke(Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:580)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:886)

Comments

jo...@meterapp.co <jo...@meterapp.co> #2Oct 24, 2024 05:29PM

Yigit, do you have time to fix it?

reemission of the same liveData is racy

jo...@meterapp.co <jo...@meterapp.co> #3Oct 24, 2024 05:30PM

yea i'll take it.

bi...@gmail.com <bi...@gmail.com> #4Oct 24, 2024 09:40PM

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.

[Deleted User] <[Deleted User]> #5Oct 29, 2024 02:09PM

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()
}
}

8h...@gmail.com <8h...@gmail.com> #6Nov 5, 2024 01:08AM

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)

jo...@meterapp.co <jo...@meterapp.co> #7Nov 13, 2024 02:51PM

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} )
}

pa...@wewell.app <pa...@wewell.app> #8Nov 14, 2024 08:36AM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019

Fix coroutine livedata race condition

This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.

We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)

Bug: 140249349
Test: BuildLiveDataTest#raceTest_*

Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40

M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt

https://android-review.googlesource.com/1112186

https://goto.google.com/android-sha1/af12e75e6b4110f48e44ca121466943909de8f06

jb...@google.com <jb...@google.com> Nov 15, 2024 07:43PM

Assigned to jb...@google.com.

ap...@google.com <ap...@google.com> #9Nov 20, 2024 02:06AM

Project: platform/frameworks/support
Branch: androidx-main
Author: Jeremy Woods <jbwoods@google.com>
Link: https://android-review.googlesource.com/3350154

Add conditional check inside NavHost PredictiveBackHandler

Expand for full commit details

Add conditional check inside NavHost PredictiveBackHandler 
 
There is no way to guarantee that we will get a composition if a state 
change and back callback get triggered in the same frame. This can 
result in triggering the `PredictiveBackHandler`'s callback even though 
it should actually be disabled. 
 
The cleaner options of fixing this are to change the 
`PredictiveBackHandler`'s `enabled` parameter to a Boolean producing 
lambda that can be executed internally and retrieve the current value, 
but that needs a new API. (see 379152996#comment2) 
 
In the meantime, we just need to add the same check inside of the 
`PredictiveBackHandler`'s lambda. 
 
RelNote: "Fixed an issue where `NavHost` could throw an exception 
inside of the `PredictiveBackHandler` if the back stack is popped down 
to 1 entry and a system back are triggered in the same frame." 
Test: added testDisabledInSameFramePredictiveBack 
Bug: 375343407 
 
Change-Id: I1a4297a10f2d0da8c8477644b9250c61e4792923

Files:

M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostPredictiveBackTest.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt

Hash: f724837c72814a08c4177004ae3e8f380eea8367
Date: Fri Nov 15 20:56:54 2024

[Deleted User] <[Deleted User]> #10Nov 22, 2024 11:26AM

"Could you please provide information on the planned release version for the fix, as well as the anticipated timeline for its deployment?"

jb...@google.com <jb...@google.com> #11Nov 25, 2024 04:52PM

Marked as fixed.

This has ben fixed internally and will be available in the Navigation 2.8.5 release.

jo...@meterapp.co <jo...@meterapp.co> #12Nov 26, 2024 04:18PM

Thank you so much for your hard work and persistence on this issue! Really excited for the 2.8.5 release :)

sh...@navi.com <sh...@navi.com> #13Dec 3, 2024 07:50PM

by when can i expect 2.8.5 to hit stable and be available to use?

jo...@meterapp.co <jo...@meterapp.co> #14Dec 5, 2024 04:15PM

#comment13

by when can i expect 2.8.5 to hit stable and be available to use?

Based on the androidx release schedule, I'd assume it will be available December 11th. It looks like they skipped the thanksgiving release for most libraries and I'm hoping they'll be back with releases December 11th. https://developer.android.com/jetpack/androidx/versions/all-channel

pr...@google.com <pr...@google.com> #15Dec 11, 2024 06:27PM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.navigation:navigation-compose:2.9.0-alpha04
androidx.navigation:navigation-compose:2.8.5

si...@gmail.com <si...@gmail.com> #16Dec 12, 2024 05:13PM

I can confirm that our usual way of reproducing this issue with the debugger no longer crashes. Thanks a lot for this release!

sa...@gmail.com <sa...@gmail.com> #17Dec 12, 2024 10:37PM

Works Well. Thank you.

ma...@wm.rs <ma...@wm.rs> #18Dec 16, 2024 12:53PM

Hi, I'm still facing the issue with 2.8.5

The stack trace:

Fatal Exception: java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 1
       at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
       at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
       at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266)
       at java.util.Objects.checkIndex(Objects.java:359)
       at java.util.ArrayList.get(ArrayList.java:434)
       at androidx.navigation.compose.NavHostKt$NavHost$28$1.invokeSuspend(NavHost.kt:620)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:101)
       at androidx.compose.ui.platform.AndroidUiDispatcher.performTrampolineDispatch(AndroidUiDispatcher.android.kt:81)
       at androidx.compose.ui.platform.AndroidUiDispatcher.access$performTrampolineDispatch(AndroidUiDispatcher.android.kt:41)
       at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.run(AndroidUiDispatcher.android.kt:57)
       at android.os.Handler.handleCallback(Handler.java:958)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at android.os.Looper.loopOnce(Looper.java:230)
       at android.os.Looper.loop(Looper.java:319)
       at android.app.ActivityThread.main(ActivityThread.java:9063)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:588)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1103)

It's seems the issue now is in val previousEntry = currentBackStack[currentBackStack.size - 2]:

if (inPredictiveBack) {
    LaunchedEffect(progress) {
        val previousEntry = currentBackStack[currentBackStack.size - 2]
        transitionState.seekTo(progress, previousEntry)
    }
}

si...@gmail.com <si...@gmail.com> #19Dec 16, 2024 04:10PM

Filed https://issuetracker.google.com/issues/384186542 for the new issue.

ba...@gmail.com <ba...@gmail.com> #20Dec 16, 2024 07:07PM

Version 2.8.5 resolved the issue. However, this time instead of throwing an exception, it neither navigates up nor navigates. No solution.