Status Update
No update yet.
Comments
ra...@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
st...@baramundi.de
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
ra...@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)
ra...@google.com
ra...@google.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
st...@baramundi.de
Great, thanks. I will take a look.
ra...@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
Version used: 1.0.0-alpha08
Devices/Android versions reproduced on: Moto G5s Plus, Android 7.1.1 / Huawai P20 lite, Android 8.0.0
We can reproduce a crash of the workmanager on some devices.
In our code we enqueue a UniqueWork with ExistingWorkPolicy.REPLACE, as soon as it finishes with State.SUCEEDED we enqueue it again. There is always only one job at the time.
After about 100 jobs the workmanager crashes with: java.lang.IllegalStateException: Apps may not schedule more than 100 distinct jobs.
It looks like the workmanager does not prune the finished jobs fast enough, and they count as 'sheduled' job, even if they are finished?
The crash is reproducible on the Moto G5s Plus and Huawai P20 lite. But it behaves very inconsistent, sometimes it occurs on the first run, sometimes only after a few restarts of the app. But we cannot reproduce it on the Pixel 2 XL or the emulator.
Calling pruneWork() before enqueue() doesn't fix the problem.
Reducing the result lifetime by calling keepResultsForAtLeast(..) doesn't work as well.
We provided a sample app which triggers the issue.