Status Update
No update yet.
Comments
ma...@google.com
as...@google.com
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
br...@monzo.com
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
as...@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)
br...@monzo.com
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.
ap...@google.com
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
br...@monzo.com
Great, thanks. I will take a look.
na...@google.com
PS: You mention that there are other crashes on the second screen.
If logcat shows the same lines like #2 i.e.
```
.../apex/com.android.runtime/lib64/bionic/libc.so (__strncmp_aarch64+252)
.../libcompose_inspection_jni.so (compose_inspection::analyzeLines(_jvmtiEnv*, int, _jvmtiLineNumberEntry*, int, _jvmtiLocalVariableEntry*, int*, int*)
.../libcompose_inspection_jni.so (compose_inspection::resolveLocation(_JNIEnv*, _jclass*)
```
then it is likely the same bug.
If crash looks different in logcat, it is likely a different bug: Please create a new bug (you could update this bug with a link to the new bug. Then I will see the new bug before the it goes through triaging).
Thank you so much for reporting.
Description
Jetpack Compose version: I've tested on 1.3.0-alpha01 and 1.2.0-beta03
Jetpack Compose component(s) used: LazyColumn
Android Studio Build: 221.3427.89.2211.8689873
Kotlin version: 1.7.10
Steps to Reproduce or Code Sample to Reproduce:
Context:
We have a rather large (10k+ items) LazyColumn where scrolling (eventually) leads to the application grinding to a halt, constantly trying to free memory. It can't, we just keep getting lots of these:
Background concurrent copying GC freed 51964(1414KB) AllocSpace objects, 6(120KB) LOS objects, 0% free, 190MB/192MB, paused 101us total 1.483sI took at heap dump at this point and basically all of the heap is used up by instances of
SnapshotMutableStateImpl$StateStateRecord.Replace LazyColumn with a RecyclerView (with each item being a ComposeView) and the memory leak is gone. App performance is night and day better.
I've been trying for hours to reproduce this in a trivial sample project and haven't had any luck yet. Raising this anyway just in case you have any ideas about what might be causing it. Obviously this makes LazyColumn completely unusable for us, so we'll stick to RecyclerView for now!