Recomposer memory leak when using ComposeView [240975572]

Fixed

Bug

Status Update

No update yet.

Description

kr...@gmail.com

created issue #1

Aug 2, 2022 07:42AM

Jetpack Compose version: 1.2.0

Android Studio Build: Android Studio Chipmunk | 2021.2.1 Patch 1

Kotlin version: 1.7.0

Steps to Reproduce or Code Sample to Reproduce:

Opening and closing an Activity that uses ComposeView causes memory leak. Here's sample code used:

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(ComposeView(this))
    }
}

LeakCanary points to Recomposer.snapshotInvalidations.

Stack trace:

====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS
References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.
62741 bytes retained by leaking objects
Signature: d96e2a7ef94b93420bf533642d3bfbd136d1ddf1
┬───
│ GC Root: Thread object
│
├─ android.net.ConnectivityThread instance
│    Leaking: NO (PathClassLoader↓ is not leaking)
│    Thread name: 'ConnectivityThread'
│    ↓ Thread.contextClassLoader
├─ dalvik.system.PathClassLoader instance
│    Leaking: NO (SnapshotKt↓ is not leaking and A ClassLoader is never leaking)
│    ↓ ClassLoader.runtimeInternalObjects
├─ java.lang.Object[] array
│    Leaking: NO (SnapshotKt↓ is not leaking)
│    ↓ Object[49]
├─ androidx.compose.runtime.snapshots.SnapshotKt class
│    Leaking: NO (Recomposer↓ is not leaking and a class is never leaking)
│    ↓ static SnapshotKt.applyObservers
├─ java.util.ArrayList instance
│    Leaking: NO (Recomposer↓ is not leaking)
│    ↓ ArrayList[10]
├─ androidx.compose.runtime.
│  Recomposer$recompositionRunner$2$unregisterApplyObserver$1 instance
│    Leaking: NO (Recomposer↓ is not leaking)
│    Anonymous subclass of kotlin.jvm.internal.Lambda
│    ↓ Recomposer$recompositionRunner$2$unregisterApplyObserver$1.this$0
├─ androidx.compose.runtime.Recomposer instance
│    Leaking: NO (Recomposer is in state PendingWork)
│    ↓ Recomposer.snapshotInvalidations
│                 ~~~~~~~~~~~~~~~~~~~~~
├─ java.util.ArrayList instance
│    Leaking: UNKNOWN
│    Retaining 81,0 kB in 1797 objects
│    ↓ ArrayList[74]
│               ~~~~
├─ java.util.HashSet instance
│    Leaking: UNKNOWN
│    Retaining 63,0 kB in 1169 objects
│    ↓ HashSet[element()]
│             ~~~~~~~~~~~
├─ androidx.compose.runtime.ParcelableSnapshotMutableState instance
│    Leaking: UNKNOWN
│    Retaining 62,8 kB in 1164 objects
│    ↓ SnapshotMutableStateImpl.next
│                               ~~~~
├─ androidx.compose.runtime.SnapshotMutableStateImpl$StateStateRecord instance
│    Leaking: UNKNOWN
│    Retaining 62,8 kB in 1163 objects
│    ↓ SnapshotMutableStateImpl$StateStateRecord.value
│                                                ~~~~~
├─ androidx.compose.ui.platform.AndroidComposeView$ViewTreeOwners instance
│    Leaking: UNKNOWN
│    Retaining 62,8 kB in 1161 objects
│    lifecycleOwner instance of com.example.MainActivity with mDestroyed = true
│    savedStateRegistryOwner instance of com.example.MainActivity with mDestroyed = true
│    ↓ AndroidComposeView$ViewTreeOwners.lifecycleOwner
│                                        ~~~~~~~~~~~~~~
╰→ com.example.MainActivity instance
     Leaking: YES (ObjectWatcher was watching this because com.example.MainActivity received
     Activity#onDestroy() callback and Activity#mDestroyed is true)
     Retaining 62,7 kB in 1160 objects
     key = 7ee8d451-c62a-46e6-b33e-77bca0a5b8d2
     watchDurationMillis = 7788
     retainedDurationMillis = 2788
     mApplication instance of com.example.DossierApplication
     mBase instance of androidx.appcompat.view.ContextThemeWrapper

Comments

so...@google.com <so...@google.com> Aug 15, 2022 03:01PM

Assigned to je...@google.com.

rh...@gmail.com <rh...@gmail.com> #2Aug 23, 2022 07:11PM

A couple of questions:

1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?

rh...@gmail.com <rh...@gmail.com> #3Aug 26, 2022 02:34PM

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

Memory-Leak-Compose-Activty-Switching-15-miuntes-graph.png

178 KB

View

Download

Memory-Leak-Compose-Activty-Switching-15-miuntes-stats.png

37 KB

View

Download

rh...@gmail.com <rh...@gmail.com> #4Aug 26, 2022 02:38PM

Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

Compose-Navigation-Switching-15-miuntes-stats.png

32 KB

View

Download

Compose-Navigation-Switching-15-miuntes-graph.png

245 KB

View

Download

an...@google.com <an...@google.com> Sep 7, 2022 04:48PM

Reassigned to ch...@google.com.

se...@gmail.com <se...@gmail.com> #5Nov 7, 2022 07:38AM

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

[Deleted User] <[Deleted User]> #6Nov 15, 2022 02:56AM

On the contrary, there was no separate process before, when crashes started.

In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)

backtrace:
  #00  pc 000000000003c7c0  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003b960  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bb48  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bafc  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000036c98  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000032714  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000031cac  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000057438  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)

se...@gmail.com <se...@gmail.com> #7Nov 17, 2022 07:49PM

FYI, ML Kit launched a new language ID SDK in the latest release, which uses a new language ID model. https://developers.google.com/ml-kit/release-notes#august_11_2021

Could you try the new SDK version(17.0.0) to check if you can still repro this native crash? Thanks!

se...@gmail.com <se...@gmail.com> #8Nov 21, 2022 05:56PM

Thank you, I'll try it and check.

lu...@perrystreet.com <lu...@perrystreet.com> #9Nov 29, 2022 01:23PM

Hello. I have similar experience.

I'm using mlkit-language 16.1.1
I didnot meet this error until using AGP 4.2
I can get this error since using AGP 7.0
This error raised on Release build only(minimized by R8)
This error raised without obfuscation.

zh...@gmail.com <zh...@gmail.com> #10Dec 24, 2022 07:21PM

Also I found there is a post which presents same issue on stackoverflow.

https://stackoverflow.com/questions/68832304/mlkit-translate-sdk-crashes-in-release-build

jo...@muzz.com <jo...@muzz.com> #11Jan 10, 2023 03:10PM

I created reproducible project.

$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp7 mlkit_agp7
$ cd mlkit_agp7
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity

$ adb logcat -b crash -d
10-19 19:41:49.844 17810 17810 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf9d733c in tid 17810 (e.myapplication), pid 17810 (e.myapplication)
10-19 19:41:50.473 17849 17849 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-19 19:41:50.473 17849 17849 F DEBUG   : Build fingerprint: 'google/crosshatch/crosshatch:12/SPB5.210812.002/7671067:user/release-keys'
10-19 19:41:50.473 17849 17849 F DEBUG   : Revision: 'MP1.0'
10-19 19:41:50.473 17849 17849 F DEBUG   : ABI: 'arm64'
10-19 19:41:50.473 17849 17849 F DEBUG   : Timestamp: 2021-10-19 19:41:49.903736988+0900
10-19 19:41:50.473 17849 17849 F DEBUG   : Process uptime: 0s
10-19 19:41:50.473 17849 17849 F DEBUG   : Cmdline: com.example.myapplication
10-19 19:41:50.474 17849 17849 F DEBUG   : pid: 17810, tid: 17810, name: e.myapplication  >>> com.example.myapplication <<<
10-19 19:41:50.474 17849 17849 F DEBUG   : uid: 10240
10-19 19:41:50.474 17849 17849 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf9d733c
10-19 19:41:50.474 17849 17849 F DEBUG   :     x0  0000000000000000  x1  00000000000008fc  x2  0000007a76760c71  x3  0000000000000000
10-19 19:41:50.474 17849 17849 F DEBUG   :     x4  0000000000000010  x5  0000007ba4db49d0  x6  0000007b34dc3680  x7  3de38e3900000608
10-19 19:41:50.474 17849 17849 F DEBUG   :     x8  0000007bb4dbedf0  x9  0000007acf9db2aa  x10 0000000000000000  x11 0000007acf9d6640
10-19 19:41:50.474 17849 17849 F DEBUG   :     x12 0000000000000009  x13 0000000000000000  x14 0000000000000061  x15 00000000ebad6a89
10-19 19:41:50.474 17849 17849 F DEBUG   :     x16 0000007a767cfef8  x17 0000007d9a564b40  x18 0000007da3830000  x19 0000007feaf56a08
10-19 19:41:50.474 17849 17849 F DEBUG   :     x20 0000000000000000  x21 0000007ba4da50b0  x22 0000007bb4dbedf0  x23 0000007ba4da50b8
10-19 19:41:50.474 17849 17849 F DEBUG   :     x24 0000000000000009  x25 000000000000067e  x26 0000000000000012  x27 0000000000000008
10-19 19:41:50.474 17849 17849 F DEBUG   :     x28 0000007b64dc8440  x29 0000000000000000
10-19 19:41:50.474 17849 17849 F DEBUG   :     lr  0000007a7678a964  sp  0000007feaf56810  pc  0000007a7678b7c0  pst 0000000060000000
10-19 19:41:50.474 17849 17849 F DEBUG   : backtrace:
10-19 19:41:50.474 17849 17849 F DEBUG   :       #00 pc 000000000003c7c0  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #01 pc 000000000003b960  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #02 pc 000000000003bb48  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #03 pc 000000000003bafc  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #04 pc 0000000000036c98  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #05 pc 00000000000324a4  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG   :       #06 pc 0000000000031b5c  /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (Java_com_google_mlkit_nl_languageid_internal_LanguageIdentificationJni_nativeIdentifyLanguage+100) (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)

But after downgrade to AGP 4.2, crash is not reproducible.

$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp42 mlkit_agp42
$ cd mlkit_agp42
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity

Also, I tried to disable inline optimizers on R8 with AGP 7.0, and crash is not reproducible.

$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp7_r8_disable_inline_optimizer  mlkit_agp7_r8
$ cd mlkit_agp7_r8
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity

lu...@gmail.com <lu...@gmail.com> #12Jan 25, 2023 05:50PM

Comment has been deleted.

Message last modified on Jan 25, 2023 07:37PM

lu...@gmail.com <lu...@gmail.com> #13Jan 25, 2023 05:56PM

Here are gradle build scan logs for each branches.
All builds were clean build, and disabled build cache.

mlkit_agp7 : https://scans.gradle.com/s/qrymdqfzwokbq
mlkit_agp42 : https://scans.gradle.com/s/b6644hzfyfhaw
mlkit_agp7_r8_disable_inline_optimizer : https://scans.gradle.com/s/c6h5hy2nxod4u
- You can see R8 debug mode on build log : https://scans.gradle.com/s/c6h5hy2nxod4u/console-log#L95

Also, I pushed to update MLKit Language Id version 17.0.1 on mlkit17_agp7 branch And here is gradle build scan

https://scans.gradle.com/s/ytaa2kkbp5vc4
- Here is version of com.google.mlkit:language-id

And here is crash log after apply 17.0.1
You can see that BuildId of liblanguage_id_l2c_jni.so was changed from 859ec0ec2000a39e6ae8ed42e1704f46 to be6e59455cc10135330c93acdebfc121

10-20 03:07:24.522 24587 24628 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf995426 in tid 24628 (pool-3-thread-3), pid 24587 (e.myapplication)
10-20 03:07:25.190 24710 24710 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-20 03:07:25.190 24710 24710 F DEBUG   : Build fingerprint: 'google/crosshatch/crosshatch:12/SPB5.210812.002/7671067:user/release-keys'
10-20 03:07:25.190 24710 24710 F DEBUG   : Revision: 'MP1.0'
10-20 03:07:25.190 24710 24710 F DEBUG   : ABI: 'arm64'
10-20 03:07:25.190 24710 24710 F DEBUG   : Timestamp: 2021-10-20 03:07:24.583346246+0900
10-20 03:07:25.190 24710 24710 F DEBUG   : Process uptime: 0s
10-20 03:07:25.190 24710 24710 F DEBUG   : Cmdline: com.example.myapplication
10-20 03:07:25.190 24710 24710 F DEBUG   : pid: 24587, tid: 24628, name: pool-3-thread-3  >>> com.example.myapplication <<<
10-20 03:07:25.190 24710 24710 F DEBUG   : uid: 10240
10-20 03:07:25.190 24710 24710 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf995426
10-20 03:07:25.190 24710 24710 F DEBUG   :     x0  0000007b54da9d30  x1  0000007d9a5fe7cc  x2  0000000000000000  x3  0000000000000010
10-20 03:07:25.190 24710 24710 F DEBUG   :     x4  0000000000000000  x5  0000007c34dbc79c  x6  0000002f0000083b  x7  000003c300002dd5
10-20 03:07:25.190 24710 24710 F DEBUG   :     x8  0000000000000001  x9  0000000000000004  x10 0000000000000010  x11 0000000000000000
10-20 03:07:25.190 24710 24710 F DEBUG   :     x12 0000000000000000  x13 000000000000217e  x14 0000007acf9932a8  x15 000000000000217e
10-20 03:07:25.190 24710 24710 F DEBUG   :     x16 0000000000000000  x17 0000007d9a564c78  x18 0000007a6ef18000  x19 0000007c34dbc580
10-20 03:07:25.190 24710 24710 F DEBUG   :     x20 0000007ca4dc7170  x21 0000007ca4dc7800  x22 0000007ca4dc71e0  x23 0000000000000000
10-20 03:07:25.190 24710 24710 F DEBUG   :     x24 0000000000000018  x25 0000000000000007  x26 0000000000000006  x27 0000000000000004
10-20 03:07:25.190 24710 24710 F DEBUG   :     x28 0000007ca4dc7090  x29 0000007cb4da9940
10-20 03:07:25.190 24710 24710 F DEBUG   :     lr  0000007a770a9624  sp  0000007a6f7de9c0  pc  0000007a770a96a8  pst 0000000020000000
10-20 03:07:25.190 24710 24710 F DEBUG   : backtrace:
10-20 03:07:25.190 24710 24710 F DEBUG   :       #00 pc 00000000000386a8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #01 pc 00000000000388a0  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #02 pc 00000000000844a0  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #03 pc 000000000008783c  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #04 pc 0000000000035fc4  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #05 pc 0000000000034954  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG   :       #06 pc 00000000000340e8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (Java_com_google_mlkit_nl_languageid_internal_ThickLanguageIdentifier_nativeIdentifyPossibleLanguages+108) (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #07 pc 00000000002d9a44  /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #08 pc 000000000020a700  /apex/com.android.art/lib64/libart.so (nterp_helper+5648) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #09 pc 00000000000cd0dc  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #10 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #11 pc 00000000000ccfa8  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #12 pc 0000000000557cb4  /system/framework/arm64/boot-framework.oat (android.os.Binder.transact+148) (BuildId: 43a571a0ad85d6451b47016336a541ecb0eb12bb)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #13 pc 000000000020b53c  /apex/com.android.art/lib64/libart.so (nterp_helper+9292) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #14 pc 00000000000b7aba  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #15 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #16 pc 00000000000a7496  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #17 pc 000000000020a044  /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #18 pc 00000000000a7360  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #19 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #20 pc 000000000009e46c  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #21 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #22 pc 00000000000d33d6  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #23 pc 000000000020ae64  /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #24 pc 000000000009df0a  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #25 pc 0000000000209124  /apex/com.android.art/lib64/libart.so (nterp_helper+52) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #26 pc 000000000009e350  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #27 pc 000000000037b9ac  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+988) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #28 pc 00000000003751d4  /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+68) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #29 pc 000000000020aec4  /apex/com.android.art/lib64/libart.so (nterp_helper+7636) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #30 pc 000000000009e370  /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG   :       #31 pc 00000000001bf35c  /apex/com.android.art/javalib/arm64/boot.oat (java.lang.Thread.run+76) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #32 pc 00000000002d0164  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #33 pc 000000000031ccac  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+156) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #34 pc 00000000003cf8a0  /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, jvalue const*)+380) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #35 pc 0000000000460894  /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+992) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #36 pc 00000000000b1910  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264) (BuildId: ba489d4985c0cf173209da67405662f9)
10-20 03:07:25.191 24710 24710 F DEBUG   :       #37 pc 00000000000513f0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: ba489d4985c0cf173209da67405662f9)

lu...@gmail.com <lu...@gmail.com> #14Jan 25, 2023 08:25PM

Cross-posted on R8 issue tracker. https://issuetracker.google.com/issues/203573699

rh...@gmail.com <rh...@gmail.com> #15Jan 25, 2023 08:29PM

Hi,

Looks like we figured out the root cause in b/203573699

For temporary workarounds for the existing SDKs, you need to add this rule

-keep class com.google.mlkit.nl.languageid.internal.LanguageIdentificationJni { *; }

for language-id 16.1.1, and add this rule

-keep class com.google.mlkit.nl.languageid.internal.ThickLanguageIdentifier { *; }

for version language-id 17.0.0+ for the newer model.

We'll fix this issue in the upcoming release so that you'll not need these workarounds in the future release.

Thanks a lot for reporting this issue!

lu...@gmail.com <lu...@gmail.com> #16Jan 26, 2023 03:06PM

Added workarounds in Known issues section in public docs.

first_capture.png

254 KB

View

Download

second_capture.png

262 KB

View

Download

lu...@gmail.com <lu...@gmail.com> #17Jan 26, 2023 03:11PM

https://issuetracker.google.com/issues/250610583

https://issuetracker.google.com/issues/250609756

https://issuetracker.google.com/issues/250609759

https://issuetracker.google.com/issues/250610272

https://issuetracker.google.com/issues/250610273

https://issuetracker.google.com/issues/250610276

https://issuetracker.google.com/issues/250610278

https://issuetracker.google.com/issues/250610593

https://issuetracker.google.com/issues/250610280

https://issuetracker.google.com/issues/250610923

https://issuetracker.google.com/issues/250610282

https://issuetracker.google.com/issues/250611106

https://issuetracker.google.com/issues/250610598

https://issuetracker.google.com/issues/250611463

https://issuetracker.google.com/issues/250611111

https://issuetracker.google.com/issues/250610933

https://issuetracker.google.com/issues/250610935

https://issuetracker.google.com/issues/250611113

https://issuetracker.google.com/issues/250610937

https://issuetracker.google.com/issues/250611116

https://issuetracker.google.com/issues/250611466

https://issuetracker.google.com/issues/250612724

https://issuetracker.google.com/issues/250612604

https://issuetracker.google.com/issues/250612726

https://issuetracker.google.com/issues/250611471

https://issuetracker.google.com/issues/250177858

https://issuetracker.google.com/issues/250172577

https://www.endezo-it.com/2022/10/the-dark-event-of-indonesian-football.html

https://www.49erssports.com/2022/10/kanjuruhan-tragedy-arema-fc-management.html

https://one-piece-red-full-movie-english.webflow.io/

https://documenter.getpostman.com/view/21828632/2s83tJGAat

fl...@polarsteps.com <fl...@polarsteps.com> #18Feb 2, 2023 07:38PM

So this essentially means that every app out there, which is in any of its activities using ComposeView(s) will leak those activities. Seems like a P1 to me.

ve...@gmail.com <ve...@gmail.com> #19Feb 10, 2023 02:08PM

There is a small demo project simulating any number of leaks (using fragment and further activities). This is a major issue, which blocking us from releasing many features using compose. They have reproducibility 100%, and have potentially huge impact on memory and performance. Could you please bump this issues to P1?

mo...@gmail.com <mo...@gmail.com> #20Feb 11, 2023 12:44AM

This is a **major** issue, open for months and still not started. Can we have an update please? The reason this doesn't have enough upvotes is because unfortunately not a lot of devs investigate memory leaks.

ve...@gmail.com <ve...@gmail.com> #21Feb 14, 2023 03:32PM

From issue 264389670 on 14/02/2023:

Please note that ComposeView is not the prerequisite for this leak, but the changing of the mutable state during hiding of composition in first activity. Although, the root cause could be the same, but this issue doesn't assume any root cause, but provides the setup for replication. Fragment is also not required. I will attach new setup, which does use only just 3 activities. And that's enough for memory leak.

Replication

From MainActivity go to IntermediateActivity
From IntermediateActivity go to ComposeActivity
From ComposeActivity go back
Checking profiler. Have memory leak

se...@journiapp.com <se...@journiapp.com> #22Feb 23, 2023 04:15PM

It is mind blowing to see that nothing was done or even communicated for so long. Issue is incredibly major and blocks ALL products from migrating to compose framework

ve...@gmail.com <ve...@gmail.com> #23Feb 27, 2023 01:02PM

This issue is drastically underestimated, probably also due to not expressive title. It's not ComposeView problem. We don't even need any long running task. It looks like Composer problem (maybe something deep in compose internals). In my opinion most of the Compose applications, which are not single-activity are impacted by this.

Any mutable state change during composition hiding is enough for replication. The impact is drastic: all subsequent compose activities are stucking in the memory, and just piling up.

wu...@gmail.com <wu...@gmail.com> #24Mar 21, 2023 03:26AM

still not fixed?

lu...@gmail.com <lu...@gmail.com> #25Mar 21, 2023 05:16PM

Perhaps. is not compose problem, and the problem is with lambda instances because that are the objects retained in the profiler- Perhasps lambda notation leaks memory. But im not no sure. , or is a combination of compose with lambda notation. The problem still exists . With this issue i prefer use old way xml layouts, and avoid to migrate to compose.

See $lambda-1$1 in the profiler

ComposableSingletons$Maintiner1Activitykt$lambda-1$1
ComposableSingletons$Maintiner1Activitykt$lambda-2$1

mg...@a-bly.com <mg...@a-bly.com> #26Mar 27, 2023 10:53AM

I made a minimal reproduction of #23.

https://github.com/zmunm/compose-leak-sample

The coil is holding the drawable as state and this overlapped and caused the oom.
I made a PR to address this.

https://github.com/coil-kt/coil/pull/1675#issuecomment-1484923260

as...@google.com <as...@google.com> #27Mar 28, 2023 05:53AM

The memory leak is caused by an edge case, when the activity is stopped while Recomposer is holding some pending state for composition. By default, MonotonicClock used in Recomposer is paused on activity stop, causing it to suspend frame iteration. It works well in most cases, as state objects in other activities are not relevant for the composition in the stopped one. In this edge case, however, the same state is used in some activities or Recomposer has already queued an update before activity was stopped, and it continues to accumulate states from other activities until the first activity is restarted or destroyed. The issue is quite deeply rooted, as the fix is likely to change how compositions record states in background, so we are targeting next release for the fix.

If you are affected by this issue in the meantime, consider specifying a custom WindowRecomposerFactory in your app that doesn't pause MonotonicClock (or unpauses it periodically). The side effect of such custom Recomposer is that compositions will continue running animations when activity is in background.

ap...@google.com <ap...@google.com> #28Apr 3, 2023 08:50PM

Marked as fixed.

Project: platform/frameworks/support
Branch: androidx-main

commit 66fef38b1d11e0c48b11137e6c3d007909f4a2d1
Author: Chuck Jazdzewski <chuckj@google.com>
Date: Wed Mar 29 13:51:01 2023

ON_STOP should pause the frame clock broadcasts instead of composition

When an Android window receives an ON_STOP noficiation it would pause
the pausable clock it created for its recomposer. This has the effect
of pausing all compositions and causes the recomposer to collect change
nofications from the snapshot sustem in an unbounded collection.

With this change, windows that receive ON_STOP will now only pause the
frame clock broadcasts which has the effect of blocking withFrameNanos
that is used by animations. This means animations stop advancing but
composition is allowed to continue allowing the recomposer to drain the
notifications from the snapshot system.

Relnote: """The recomposer created for an Android window will now
only block calls to `withFrameNanos` instead of all composition when it
receives an ON_STOP notification. This means windows associated with
stopped activites will continue to recompose for data changes but the
animations, or any other caller of withFrameNanos, will block."""

Fixes: 240975572
Test: ./gradlew :compose:r:r:tDUT
Change-Id: Id9e7fe262710544a48c2e4fc5fcbf1d27bfaa1ba

M compose/runtime/runtime/api/current.txt
M compose/runtime/runtime/api/public_plus_experimental_current.txt
M compose/runtime/runtime/api/restricted_current.txt
M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/Recomposer.kt
M compose/runtime/runtime/src/commonTest/kotlin/androidx/compose/runtime/RecomposerTests.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/WindowRecomposer.android.kt

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

ma...@xapo.com <ma...@xapo.com> #29Apr 12, 2023 07:50AM

Does anyone have an estimation when the fix will be available in production?
This leak is happening for us on every screen migrated to Compose and would like to check any alpha version for the fix.

ch...@google.com <ch...@google.com> #30Apr 12, 2023 04:21PM

This is in android-main which is now the 1.5 branch. It should be out with the next alpha of 1.5 but not stable until 1.5 is stable.

pr...@google.com <pr...@google.com> #31Apr 19, 2023 06:13PM

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

androidx.compose.runtime:runtime:1.5.0-alpha03
androidx.compose.ui:ui:1.5.0-alpha03

lu...@gmail.com <lu...@gmail.com> #32Apr 21, 2023 01:46PM

I already tested with

androidx.compose.runtime:runtime:1.5.0-alpha03
androidx.compose.ui:ui:1.5.0-alpha03

But the problems still exists

ComposableSingletons$Activitykt$lambda-1$1. never are released . The Activity is released. but the composables are always keep it in memory, so its seems to be a kind of memory leak

lu...@gmail.com <lu...@gmail.com> #33Apr 21, 2023 03:05PM

As a conclusion: ComposableSingletons are part of composable and will never release during all tha app. So its part of the framework itself

aa...@gmail.com <aa...@gmail.com> #34Apr 26, 2023 03:30AM

How does version 1.4.x handle this bug?

xu...@gmail.com <xu...@gmail.com> #35May 11, 2023 12:01PM

Is it still not resolved?

ma...@gmail.com <ma...@gmail.com> #36Sep 28, 2023 06:07AM

It is resolved here:

https://android-developers.googleblog.com/2023/08/whats-new-in-jetpack-compose-august-23-release.html

[Deleted User] <[Deleted User]> #37Oct 11, 2023 09:29AM

I have upgraded to the version mentioned in the article but the issue still persists. Could someone confirm if the issue is fixed.

ch...@google.com <ch...@google.com> #38Oct 11, 2023 01:07PM

Lambdas like ComposableSingletons$Maintiner1Activitykt$lambda-1$1, as the name implies, are lazy allocated singleton instances that are stored globally. They will only be allocated once. This is not addressed by the above fix because it is not a leak but a singlton.

lu...@gmail.com <lu...@gmail.com> #39Dec 18, 2023 02:00PM

But you have to be very carefully with Singleton in Android. As you remark singleton are allocated once , but it not leaved untill app leaves, so supose you have old navigation with many activities , this ComposableSingleton are allocated and never released untill you leave the app. I think if its part of composable framework this is dangerous because they are keeping memory releated to an activity that is eventually finished

lu...@gmail.com <lu...@gmail.com> #40Dec 18, 2023 02:43PM

Comment has been deleted.

Message last modified on Dec 18, 2023 07:31PM

lu...@gmail.com <lu...@gmail.com> #41Dec 18, 2023 07:58PM

With latest version 'androidx.activity:activity-compose:1.8.2' the leacked acivity has gonne, but still have instance of

ComposableSingletons$Activitykt$lambda-1$1. that keep in memory

I think is part of the composable framework

Issue 240975572

Description

Issue summary

Comments

so...@google.com <so...@google.com> Aug 15, 2022 03:01PM

rh...@gmail.com <rh...@gmail.com> #2Aug 23, 2022 07:11PM

rh...@gmail.com <rh...@gmail.com> #3Aug 26, 2022 02:34PM

rh...@gmail.com <rh...@gmail.com> #4Aug 26, 2022 02:38PM

an...@google.com <an...@google.com> Sep 7, 2022 04:48PM

se...@gmail.com <se...@gmail.com> #5Nov 7, 2022 07:38AM

[Deleted User] <[Deleted User]> #6Nov 15, 2022 02:56AM

se...@gmail.com <se...@gmail.com> #7Nov 17, 2022 07:49PM

se...@gmail.com <se...@gmail.com> #8Nov 21, 2022 05:56PM

lu...@perrystreet.com <lu...@perrystreet.com> #9Nov 29, 2022 01:23PM

zh...@gmail.com <zh...@gmail.com> #10Dec 24, 2022 07:21PM

jo...@muzz.com <jo...@muzz.com> #11Jan 10, 2023 03:10PM

lu...@gmail.com <lu...@gmail.com> #12Jan 25, 2023 05:50PM

lu...@gmail.com <lu...@gmail.com> #13Jan 25, 2023 05:56PM

lu...@gmail.com <lu...@gmail.com> #14Jan 25, 2023 08:25PM

rh...@gmail.com <rh...@gmail.com> #15Jan 25, 2023 08:29PM

lu...@gmail.com <lu...@gmail.com> #16Jan 26, 2023 03:06PM

lu...@gmail.com <lu...@gmail.com> #17Jan 26, 2023 03:11PM

fl...@polarsteps.com <fl...@polarsteps.com> #18Feb 2, 2023 07:38PM

ve...@gmail.com <ve...@gmail.com> #19Feb 10, 2023 02:08PM

mo...@gmail.com <mo...@gmail.com> #20Feb 11, 2023 12:44AM

ve...@gmail.com <ve...@gmail.com> #21Feb 14, 2023 03:32PM

se...@journiapp.com <se...@journiapp.com> #22Feb 23, 2023 04:15PM

ve...@gmail.com <ve...@gmail.com> #23Feb 27, 2023 01:02PM

wu...@gmail.com <wu...@gmail.com> #24Mar 21, 2023 03:26AM

lu...@gmail.com <lu...@gmail.com> #25Mar 21, 2023 05:16PM

mg...@a-bly.com <mg...@a-bly.com> #26Mar 27, 2023 10:53AM

as...@google.com <as...@google.com> #27Mar 28, 2023 05:53AM

ap...@google.com <ap...@google.com> #28Apr 3, 2023 08:50PM

ma...@xapo.com <ma...@xapo.com> #29Apr 12, 2023 07:50AM

ch...@google.com <ch...@google.com> #30Apr 12, 2023 04:21PM

pr...@google.com <pr...@google.com> #31Apr 19, 2023 06:13PM

lu...@gmail.com <lu...@gmail.com> #32Apr 21, 2023 01:46PM

lu...@gmail.com <lu...@gmail.com> #33Apr 21, 2023 03:05PM

aa...@gmail.com <aa...@gmail.com> #34Apr 26, 2023 03:30AM

xu...@gmail.com <xu...@gmail.com> #35May 11, 2023 12:01PM

ma...@gmail.com <ma...@gmail.com> #36Sep 28, 2023 06:07AM

[Deleted User] <[Deleted User]> #37Oct 11, 2023 09:29AM

ch...@google.com <ch...@google.com> #38Oct 11, 2023 01:07PM

lu...@gmail.com <lu...@gmail.com> #39Dec 18, 2023 02:00PM

lu...@gmail.com <lu...@gmail.com> #40Dec 18, 2023 02:43PM

lu...@gmail.com <lu...@gmail.com> #41Dec 18, 2023 07:58PM

Add comment

Issue metadata