You cannot access the NavBackStackEntry's ViewModels after the NavBackStackEntry is destroyed. [228865698]

Fixed

Bug

Status Update

No update yet.

Description

b9...@gmail.com

created issue #1

Apr 12, 2022 10:17AM

Version used: 2.5.0-alpha06

After upgraded Lifecycle to 2.5.0-alpha06, the nested NavHost navigation will crash.

open app, starting with "ok" tab.
tap "hello" tab, which has NavHost own.
tab "would" tab, app crash.

p.s. I keep the old version dependencies in build.gradle, you could try the working version.

java.lang.IllegalStateException: You cannot access the NavBackStackEntry's ViewModels after the NavBackStackEntry is destroyed.
        at androidx.navigation.NavBackStackEntry.getViewModelStore(NavBackStackEntry.kt:202)
        at androidx.lifecycle.ViewModelProvider.<init>(ViewModelProvider.kt:130)
        at androidx.lifecycle.SavedStateHandleSupport.getSavedStateHandlesVM(SavedStateHandleSupport.kt:109)
        at androidx.lifecycle.SavedStateHandlesProvider$viewModel$2.invoke(SavedStateHandleSupport.kt:134)
        at androidx.lifecycle.SavedStateHandlesProvider$viewModel$2.invoke(SavedStateHandleSupport.kt:133)
        at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
        at androidx.lifecycle.SavedStateHandlesProvider.getViewModel(SavedStateHandleSupport.kt:133)
        at androidx.lifecycle.SavedStateHandlesProvider.saveState(SavedStateHandleSupport.kt:146)
        at androidx.savedstate.SavedStateRegistry.performSave(SavedStateRegistry.java:262)
        at androidx.savedstate.SavedStateRegistryController.performSave(SavedStateRegistryController.kt:81)
        at androidx.navigation.NavBackStackEntry.saveState(NavBackStackEntry.kt:236)
        at androidx.navigation.NavBackStackEntryState.<init>(NavBackStackEntryState.kt:37)
        at androidx.navigation.NavController.saveState(NavController.kt:2032)
        at androidx.navigation.compose.NavHostControllerKt$NavControllerSaver$1.invoke(NavHostController.kt:81)
        at androidx.navigation.compose.NavHostControllerKt$NavControllerSaver$1.invoke(NavHostController.kt:80)
        at androidx.compose.runtime.saveable.SaverKt$Saver$1.save(Saver.kt:66)
        at androidx.compose.runtime.saveable.RememberSaveableKt$rememberSaveable$1$valueProvider$1.invoke(RememberSaveable.kt:100)
        at androidx.compose.runtime.saveable.SaveableStateRegistryImpl.performSave(SaveableStateRegistry.kt:136)
        at androidx.compose.runtime.saveable.SaveableStateHolderImpl$RegistryHolder.saveTo(SaveableStateHolder.kt:125)
        at androidx.compose.runtime.saveable.SaveableStateHolderImpl$SaveableStateProvider$1$1$invoke$$inlined$onDispose$1.dispose(Effects.kt:484)
        at androidx.compose.runtime.DisposableEffectImpl.onForgotten(Effects.kt:85)
        at androidx.compose.runtime.CompositionImpl$RememberEventDispatcher.dispatchRememberObservers(Composition.kt:985)
        at androidx.compose.runtime.CompositionImpl.applyChangesInLocked(Composition.kt:767)
        at androidx.compose.runtime.CompositionImpl.applyChanges(Composition.kt:785)
        at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$2.invoke(Recomposer.kt:526)
        at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$2.invoke(Recomposer.kt:454)
        at androidx.compose.ui.platform.AndroidUiFrameClock$withFrameNanos$2$callback$1.doFrame(AndroidUiFrameClock.android.kt:34)
        at androidx.compose.ui.platform.AndroidUiDispatcher.performFrameDispatch(AndroidUiDispatcher.android.kt:109)
        at androidx.compose.ui.platform.AndroidUiDispatcher.access$performFrameDispatch(AndroidUiDispatcher.android.kt:41)
        at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.doFrame(AndroidUiDispatcher.android.kt:69)
        at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1035)
        at android.view.Choreographer.doCallbacks(Choreographer.java:845)
        at android.view.Choreographer.doFrame(Choreographer.java:775)
        at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022)
        at android.os.Handler.handleCallback(Handler.java:938)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loopOnce(Looper.java:201)
        at android.os.Looper.loop(Looper.java:288)
        at android.app.ActivityThread.main(ActivityThread.java:7839)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)

MyApplication.zip

113 KB

Download

Comments

il...@google.com <il...@google.com> Apr 13, 2022 11:47PM

Assigned to il...@google.com.

ap...@google.com <ap...@google.com> #2Apr 14, 2022 03:56AM

Indexing also runs indefinitely here with Android studio 3.3 and a project that contains a NDK library (native engine + game). Previous versions, for instance 3.2.1, worked fine. Still occurs after clearing the caches and deleting the .idea folder. On a desktop with 32 GB of RAM it's not running out of memory but it indexes forever, pegging an entire CPU and disk access to 100%, and it never stops. The same thing occurs with gradle 4.6 or 4.10. If I enable the experimental scan active configuration only setting, everything is basically broken - no syntax highlighting, cpp files don't show. Waiting to see if there's a workaround before reverting to 3.2.1 and being much more cautious about updating in the future ..

b9...@gmail.com <b9...@gmail.com> #3Apr 14, 2022 07:11AM

When I let it run for hours, the scanning eventually did complete, then the indexing took more hours, I let it run as well, and eventually it switched to 'building symbols' which also started taking a long time without progress, but that, eventually, crashed Android Studio with an out of memory error, telling me to increase the heap size. I did, and upon restarting Android Studio, it started over at scanning .. so I gave up for now. This is with a mid-size NDK project.

il...@google.com <il...@google.com> #4Apr 14, 2022 04:26PM

Marked as fixed.

Even after a dirty downgrade to AS 3.2 from 3.3 my project was stuck on scanning files to index and building symbols. I ended up having to fully remove all Android Studio files/folders. After relaunching AS 3.2 and setting heap size to 8GB the scanning, indexing and building symbols took just a couple minutes.

mc...@gmail.com <mc...@gmail.com> #5May 5, 2022 07:09PM

These were the folders I deleted:
rm -rfv ~/Library/Application\ Support/AndroidStudio*
rm -rfv ~/Library/Preferences/AndroidStudio*
rm -rfv ~/Library/Caches/AndroidStudio*
rm -rfv ~/Library/Logs/AndroidStudio*
rm -rfv ~/.AndroidStudio*

tr...@gmail.com <tr...@gmail.com> #6May 5, 2022 07:34PM

Any chance someone has a repro project they can share?
@brigham, are you saying deleting those folders help with your issue?

il...@google.com <il...@google.com> #7May 5, 2022 09:55PM

@tianyu, just a heads up, this may be related to the configuration cache issue you've been looking at.

za...@groundcrewdev.com <za...@groundcrewdev.com> #8Oct 5, 2022 07:48PM

I am facing the exact same issues here. I have two projects where I build native code outside of Android Studio (Cygwin shell + ndk-build.cmd) and that goes fine in AS 3.3. But one project where I use externalNativeBuild in the gradle file has the same issues as described here. The native library part is not that big (couple of .cpp and ..h files). It is like it is scanning the entire NDK. Switching back to AS 3.2 solves it.

Update: if I use Process Monitor I can see it scan my entire disk: studio64.exe accesses even my Pictures folder!

jb...@google.com <jb...@google.com> #9Oct 5, 2022 07:56PM

Thanks Jomo and everyone. We recently identified a bug that could be related to this.

Hi Davy, can you share the directory structure of your project. Where is the NDK located with respect to the project? Also where are your cpp files with respect to the rest of the project files?

za...@groundcrewdev.com <za...@groundcrewdev.com> #10Oct 5, 2022 08:11PM

On my end, the files built into the native library are outside the project tree seen by Android Studio (they're accessed in the CMakeList file with eg. ../../../../folder/file.cpp). It sounds like this may trigger the issue

il...@google.com <il...@google.com> #11Oct 5, 2022 08:16PM

@Emmanuel, do you have only sources outside of the project tree or also CMakeLists.txt?

li...@gmail.com <li...@gmail.com> #12Jul 29, 2023 12:58PM

Only the sources; CMakeLists.txt is under "app" in the tree that is seen by Android Studio

[Deleted User] <[Deleted User]> #13Aug 1, 2023 11:32AM

Thanks for looking into this btw, much appreciated!

sa...@bluevine.com <sa...@bluevine.com> #14Aug 2, 2023 02:34PM

Common factor here seems to be that cpp files are located out of android studio/gradle directory structure.

In our case, we use separate android module/library to build cpp files. That module is not a subdirectory of the root project, but located ../../xxx/yyy location. cpp files that this module builds, are also located in multiple levels down from module root level. eg ../../xx/yy.

I think there is a bug somewhere where it resolves the paths. I'm quite sure that it would work if I create enough empty dummy directories before android studio directory, so that it would not leak out from there, or a separate empty disk image for project :)

This "scanning files bug" has been there also in 3.3 preview. I reported that here

https://issuetracker.google.com/issues/112927150 on August 2018.

ra...@gmail.com <ra...@gmail.com> #15Aug 24, 2023 04:39AM

@tg
The NDK is in a subfolder of F:\Android
CPP files are in subfolders of the project's src/main/jni folder (F:\Development\AS\USBTester\USBTester\src\main\jni)

I have a zip file with a project I can send to you if you contact me privately.

jb...@google.com <jb...@google.com> #16Aug 24, 2023 02:26PM

Thanks Davy, I'm emailing you privately

re...@gmail.com <re...@gmail.com> #17Feb 20, 2024 09:15AM

Same situation and same problem with 3.3: we've got cpp files outside of (C:\programs\projectName\src) our Android Studio project structure (C:\programs\projectName\build\android). Android Studio indexes the entire drive and runs out of memory while "loading symbols" and crashes.

In the app.iml file, it looks like Android Studio has added C:\ as a sources root. Manually changing that to C:\programs\projectName and restarting Android Studio causes the first round of indexing to complete quickly and behave normally for a few seconds, after which it overwrites the file almost immediately with the same C:\ sources root again, after which it enters the same indexing loop forever.