CarAppService memory leak reported by leakcanary [203594731]

Fixed

Bug

Status Update

No update yet.

Description

ky...@mapbox.com

created issue #1

Oct 20, 2021 01:40AM

Android Auto version reproduced on: 1.0.0

Sample project to trigger the issue. hellocar.zip is attached
A bug report https://github.com/square/leakcanary/issues/2191

Copy paste from the leakcanary issue below

I was digging into a leak that I thought was our implementation. But found that a minimal project also receives leaks. It's attached. I'm sharing here because maybe the leakcanary folks recognize this error. I'll share a google issue tracker after posting.

implementation("androidx.car.app:app:1.0.0")
implementation("com.squareup.leakcanary:leakcanary-android:2.7")

Repro steps

open app
run ./desktop_head_unit
close dhu
repeat 2 and 3

LeakTrace information

10-19 18:23:47.833 29746 30639 D LeakCanary: ====================================
10-19 18:23:47.833 29746 30639 D LeakCanary: HEAP ANALYSIS RESULT
10-19 18:23:47.833 29746 30639 D LeakCanary: ====================================
10-19 18:23:47.833 29746 30639 D LeakCanary: 1 APPLICATION LEAKS
10-19 18:23:47.833 29746 30639 D LeakCanary:
10-19 18:23:47.833 29746 30639 D LeakCanary: References underlined with "~~~" are likely causes.
10-19 18:23:47.833 29746 30639 D LeakCanary: Learn more at https://squ.re/leaks.
10-19 18:23:47.833 29746 30639 D LeakCanary:
10-19 18:23:47.833 29746 30639 D LeakCanary: 1701 bytes retained by leaking objects
10-19 18:23:47.833 29746 30639 D LeakCanary: Signature: 27a828a15f5634ec1f03e7566ebb7d680ca4d
10-19 18:23:47.833 29746 30639 D LeakCanary: ┬───
10-19 18:23:47.833 29746 30639 D LeakCanary: │ GC Root: Global variable in native code
10-19 18:23:47.833 29746 30639 D LeakCanary: │
10-19 18:23:47.833 29746 30639 D LeakCanary: ├─ androidx.car.app.CarAppService$1 instance
10-19 18:23:47.833 29746 30639 D LeakCanary: │    Leaking: UNKNOWN
10-19 18:23:47.833 29746 30639 D LeakCanary: │    Retaining 528 B in 1 objects
10-19 18:23:47.833 29746 30639 D LeakCanary: │    Anonymous subclass of androidx.car.app.ICarApp$Stub
10-19 18:23:47.833 29746 30639 D LeakCanary: │    this$0 instance of com.mapbox.example.hellocar.MainCarAppService
10-19 18:23:47.833 29746 30639 D LeakCanary: │    ↓ CarAppService$1.this$0
10-19 18:23:47.833 29746 30639 D LeakCanary: │                      ~~~~~~
10-19 18:23:47.833 29746 30639 D LeakCanary: ╰→ com.mapbox.example.hellocar.MainCarAppService instance
10-19 18:23:47.833 29746 30639 D LeakCanary:      Leaking: YES (ObjectWatcher was watching this because com.mapbox.example.hellocar.MainCarAppService received
10-19 18:23:47.833 29746 30639 D LeakCanary:      Service#onDestroy() callback and Service not held by ActivityThread)
10-19 18:23:47.833 29746 30639 D LeakCanary:      Retaining 1.7 kB in 23 objects
10-19 18:23:47.833 29746 30639 D LeakCanary:      key = 96cda5f8-8de4-44ef-b1df-641fbc38868f
10-19 18:23:47.833 29746 30639 D LeakCanary:      watchDurationMillis = 349897
10-19 18:23:47.833 29746 30639 D LeakCanary:      retainedDurationMillis = 344896
10-19 18:23:47.833 29746 30639 D LeakCanary:      mApplication instance of android.app.Application
10-19 18:23:47.833 29746 30639 D LeakCanary:      mBase instance of android.app.ContextImpl
10-19 18:23:47.833 29746 30639 D LeakCanary: ====================================
10-19 18:23:47.833 29746 30639 D LeakCanary: 0 LIBRARY LEAKS
10-19 18:23:47.833 29746 30639 D LeakCanary:
10-19 18:23:47.833 29746 30639 D LeakCanary: A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
10-19 18:23:47.833 29746 30639 D LeakCanary: See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
10-19 18:23:47.833 29746 30639 D LeakCanary: ====================================
10-19 18:23:47.833 29746 30639 D LeakCanary: 0 UNREACHABLE OBJECTS
10-19 18:23:47.833 29746 30639 D LeakCanary:
10-19 18:23:47.833 29746 30639 D LeakCanary: An unreachable object is still in memory but LeakCanary could not find a strong reference path
10-19 18:23:47.833 29746 30639 D LeakCanary: from GC roots.
10-19 18:23:47.833 29746 30639 D LeakCanary: ====================================
10-19 18:23:47.833 29746 30639 D LeakCanary: METADATA
10-19 18:23:47.833 29746 30639 D LeakCanary:
10-19 18:23:47.833 29746 30639 D LeakCanary: Please include this in bug reports and Stack Overflow questions.
10-19 18:23:47.833 29746 30639 D LeakCanary:
10-19 18:23:47.833 29746 30639 D LeakCanary: Build.VERSION.SDK_INT: 30
10-19 18:23:47.833 29746 30639 D LeakCanary: Build.MANUFACTURER: Google
10-19 18:23:47.833 29746 30639 D LeakCanary: LeakCanary version: 2.7
10-19 18:23:47.833 29746 30639 D LeakCanary: App process name: com.mapbox.example.hellocar
10-19 18:23:47.833 29746 30639 D LeakCanary: Stats: LruCache[maxSize=3000,hits=2200,misses=57518,hitRate=3%]
10-19 18:23:47.833 29746 30639 D LeakCanary: RandomAccess[bytes=2808620,reads=57518,travel=25796092554,range=20186019,size=25983967]
10-19 18:23:47.833 29746 30639 D LeakCanary: Heap dump reason: user request
10-19 18:23:47.833 29746 30639 D LeakCanary: Analysis duration: 2773 ms
10-19 18:23:47.833 29746 30639 D LeakCanary: Heap dump file path: /storage/emulated/0/Download/leakcanary-com.mapbox.example.hellocar/2021-10-19_18-23-43_310.hprof
10-19 18:23:47.833 29746 30639 D LeakCanary: Heap dump timestamp: 1634693027822
10-19 18:23:47.833 29746 30639 D LeakCanary: Heap dump duration: 1328 ms
10-19 18:23:47.833 29746 30639 D LeakCanary: ====================================
10-19 18:23:47.882 29746 29746 D LeakCanary: Watching instance of leakcanary.internal.HeapAnalyzerService (leakcanary.internal.HeapAnalyzerService received Service#onDestroy() callback) with key 26fbb319-5266-4de9-91d0-dd86d03c2918

hellocar.zip

797 KB

Download

Comments

ky...@mapbox.com <ky...@mapbox.com> #2Oct 20, 2021 09:02PM

Tentatively, the annotation should be something use-case-specific like @OutlinedNewApi that allows alternative build systems (e.g. not R8/D8) to make their own decisions. We'll provide a default Proguard configuration for R8, but it's not guaranteed this will work as intended -- outlining is automatic in newer versions, but it may be disabled.

sh...@google.com <sh...@google.com> #3Oct 25, 2021 04:12PM

Assigned to sh...@google.com.

Just as an FYI, this was enabled in AGP 2 years ago (AGP 7.3 as far as I remember), ag/18426192, so for AGP users it might fine to just remove the rule for @DoNotInline. I like the @OutlinedNewApi to make it clear what this is for other consumers to handle it as they see fit.

sh...@google.com <sh...@google.com> Jan 4, 2022 06:26PM

Accepted by sh...@google.com.

ap...@google.com <ap...@google.com> #4Jan 6, 2022 06:20AM

This article from Morten Krogh-Jespersen suggests it wasn't (perma-)enabled by default until AGP 8.1, which is only <redacted>% of users.

Given the failure mode can include run-time crashes, that's not an acceptable level of usage.

sh...@google.com <sh...@google.com> #5Jan 6, 2022 11:27PM

Marked as fixed.

I think you can still include a top-level proguard.txt, and it will be used by versions that do not support the com.android.tools format. E.g. Kotlin Coroutines library does this

ma...@gmail.com <ma...@gmail.com> #6Oct 4, 2022 08:57PM

Yeah, I that combined with r8-upto is the right approach. comment#4 is in regard to the idea that we should remove the annotations from source instead of gating the rules on R8 version.