NavController.setGraph does not reset back stack [111450672]

Fixed

Bug

Status Update

No update yet.

Description

jf...@gmail.com

created issue #1

Jul 16, 2018 02:59AM

Library name: Navigation
Library version: 1.0.0-alpha03

When setting a new NavGraph to NavController, the back stack is not resetted.
From the documentation, "Any current navigation graph data will be replaced."
If a NavGraph is already setted then the back stack containts the default destination. In calling NavGraph.setGraph(NavGraph) and in the new graph, the destination is different, then the new destination is not displayed because back stack is not resetted.
Is it expected feature or not?

Comments

il...@google.com <il...@google.com> #2Jul 17, 2018 06:16PM

Thanks for the report!

Could you please confirm for us which version of Compose is your project using? Does it happen if you change the version?

Relevant crash from device:

2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A    NOTE: Function names and BuildId information is missing for some frames due
                                                                                                      NOTE: to unreadable libraries. For unwinds of apps, only shared libraries
                                                                                                      NOTE: found under the lib/ directory are readable.
                                                                                                      NOTE: On this device, run setenforce 0 to make the libraries readable.
                                                                                                      NOTE: Unreadable libraries:
                                                                                                      NOTE:   /data/data/com.app.work/cache/androidx.compose.ui-ui-1.2.0-rc03-inspector.jar_unpacked_lib/libcompose_inspection_jni.so
2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A        #00 pc 000000000004b5bc  /apex/com.android.runtime/lib64/bionic/libc.so (__strncmp_aarch64+252) (BuildId: 058e3ec96fa600fb840a6a6956c6b64e)
2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A        #01 pc 00000000000028f4  /data/data/com.app.work/cache/androidx.compose.ui-ui-1.2.0-rc03-inspector.jar_unpacked_lib/libcompose_inspection_jni.so (compose_inspection::analyzeLines(_jvmtiEnv*, int, _jvmtiLineNumberEntry*, int, _jvmtiLocalVariableEntry*, int*, int*)+160) (BuildId: 0990d56fd5c4090102a504def1e5a1657300399e)
2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A        #02 pc 0000000000002eb4  /data/data/com.app.work/cache/androidx.compose.ui-ui-1.2.0-rc03-inspector.jar_unpacked_lib/libcompose_inspection_jni.so (compose_inspection::resolveLocation(_JNIEnv*, _jclass*)+840) (BuildId: 0990d56fd5c4090102a504def1e5a1657300399e)
2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A        #03 pc 0000000000440154  /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: 5de55fd6e2a9191dd8c1362ea79ef5f6)
2022-07-05 03:42:05.712 13983-13983 DEBUG                   pid-13983                            A        #04 pc 000000000044049c  /apex/com.android.art/lib64/libart.so (BuildId: 5de55fd6e2a9191dd8c1362ea79ef5f6)
2022-07-05 03:42:05.730   771-771   tombstoned              tombstoned                           E  Tombstone written to: tombstone_09

ha...@googlemail.com <ha...@googlemail.com> #3Jul 17, 2018 08:41PM

I can confirm same crash
composeVersion = '1.2.0-beta03'
+ these deps included
debugImplementation "androidx.compose.ui:ui-tooling:$composeVersion"
debugImplementation "androidx.compose.ui:ui-tooling-preview:$composeVersion"
debugImplementation "androidx.customview:customview:1.2.0-alpha01"
debugImplementation "androidx.customview:customview-poolingcontainer:1.0.0-rc01"

also tested 1.2.0-beta02, 1.3.0-alpha01 (with 1.2.0 composeCompiler)..., same crash

il...@google.com <il...@google.com> #4Jul 23, 2018 11:04PM

Assigned to il...@google.com.

I was using Compose 1.2.0-rc03 and Compose Compiler 1.2.0. But this issue was present in previous versions (1.2.0-RCxx) of the compiler too.

Yesterday I was testing how it works with Compose 1.1.1 and Compose 1.3.0-alpha01. It seemed to be working better, I could inspect the app for 5-10 minutes until it crashed. However, fetching view atributes was really unreliable: sometimes instantaneous, other times with a huge delay or not it all. And I believe crashes are related to the attributes section.

Most of the crashes had these messages in the Logcat afterwards: (see the attached file)

bo...@gmail.com <bo...@gmail.com> #5Sep 17, 2018 01:24PM

It looks like jvmti->GetMethodName(methodId, &name, nullptr, nullptr) returns a nullptr for name without returning an error.

Slightly surprising. I will add a nullptr guard to avoid this.

It would be nice to find out what the kotlin code that causes looks like. It will be a lambda expression.

il...@google.com <il...@google.com> Jan 11, 2019 01:22AM

Accepted by il...@google.com.

il...@google.com <il...@google.com> #6Jan 11, 2019 10:59PM

Marked as fixed.

Okay, I did some testing and found out that this code crashes the app while using Layout Inspector. Once I removed all the parameters of ModalBottomSheetState (or of my wrapper *UiState class with ModalBottomSheetState in constructor) – it began to work fine.

I have other crashes on second screen and there are no functions with parameter ModalBottomSheetState. That screen has much more functions and I will need more time to find the cause. At least it's safe to say that this the crash is not caused by ModalBottomSheetState exclusively

lb...@gmail.com <lb...@gmail.com> #7Sep 6, 2024 10:29PM

Great, thanks. I will take a look.