ViewGroup.ViewLocationHolder leak in Android P #1081
Labels
Milestone
Comments
|
Can you share the full text leaktrace (click ... in the top right)? |
|
sure thing: here is a heap dump file too. but it's not for this particular leak, for a similar one.just in case. |
|
I'm seeing a similar thing too from ReportFragment. Although in our case I am more inclined to believe we are doing something stupid with our app 😃. Here's our leak trace for comparison My.Leak.Trace.txt. I'm happy to raise this in a different issue if it's better that way. |
|
For me, the |
|
Similar issue on Oreo(S8+) and Android Pie(Pixel2XL). Note that your work Guys, is really highly appreciated. Thanks. |
|
hi I got the leak on Pixel Emulator running Android 8.1 too, here is my leak trace |
|
I've filed a bug with a repro case here for anyone that wants to follow: https://issuetracker.google.com/issues/112792715 |
|
Am I the only one or did they hide the issue from the public? oO |
|
Yes. A comment was left before doing so to notify watchers. It is also
already fixed.
…On Wed, Aug 22, 2018 at 3:59 PM Paul Woitaschek ***@***.***> wrote:
Am I the only one or did they hide the issue from the public? oO
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1081 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEEETmcmCzof13yl_P8WI01Ysb80W_nks5uTbgmgaJpZM4Vvzbx>
.
|
|
Thanks, found the mail. If someone is wondering:
|
|
So this is an Android issue starting with Oreo? It also occurs on a Pixel with Android Pie. Will this be fixed in a monthly security update or do we have to wait for Android 9.1 or even 10? |
|
You'll have to wait till it's fixed in AOSP. It's such a nuisance that I've actually just disabled leakcanary on P all together :/ |
|
For late readers, this is the proper leaktrace: |
|
Reopening because we can document a gist that uses reflection to fix this: Latest ViewGroup sources: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java This leaks happens whenever In other words, as far as I can see, ViewGroup.ViewLocationHolder is only ever used as a temporary object to sort the list of children in ViewGroup.ChildListForAccessibility, once per That happens in ViewGroup.addChildrenForAccessibility and ViewGroup.dispatchPopulateAccessibilityEventInternal. Here's an idea:
|
pyricau
changed the title
NasaGeek
added a commit
to NasaGeek/utexas-utilities
that referenced
this issue
Nov 3, 2018
Took a stab at this, in ActivityRefWatcher: On API 28, attempting to access More here: https://developer.android.com/about/versions/pie/restrictions-non-sdk-interfaces. Given this is a leak in AOSP, should we file a feature request to move the pertinent classes to the |
|
Unfortunate bad luck! |
This was referenced Feb 12, 2019
|
I have a similar problem, but the solution above did not help me. |
|
Is there any way to suppress the LeakCanary notification for this individual type of leak? I know it's a real issue, and LeakCanary reporting it means that LeakCanary is doing its job correctly. However, because we have no control over fixing it, being notified every time it happens isn't particularly useful. The other alternative would be to disable LeakCanary entirely for the app which would be throwing out the baby with the bathwater. Edit: I see there is AndroidExcludedRefs.java. Seems like this leak should be included in the list. Edit2: This leak is included in AndroidExcludedRefs.java, but it is not package com.squareup.leakcanary
import android.app.Application
import com.squareup.leakcanary.AndroidExcludedRefs.VIEWLOCATIONHOLDER_ROOT
fun buildAndInstallLeakCanary(app: Application) {
val excludedRefsBuilder: ExcludedRefs.Builder = ExcludedRefs.builder()
AndroidExcludedRefs
.values()
.filter { it.applies }
.forEach { ref ->
if (ref == VIEWLOCATIONHOLDER_ROOT) {
excludedRefsBuilder
.instanceField("android.view.ViewGroup\$ViewLocationHolder", "mRoot")
.alwaysExclude()
.staticField("android.view.ViewGroup\$ViewLocationHolder", "sPool")
.alwaysExclude()
} else {
ref.add(excludedRefsBuilder)
}
(excludedRefsBuilder as ExcludedRefs.BuilderWithParams).named(ref.name)
}
LeakCanary.refWatcher(app)
.excludedRefs(excludedRefsBuilder.build())
.buildAndInstall()
} |
|
@jrodbx Have you filed a feature request to move the relevant classes to the light greylist? If so, please link it, as I'd like to follow the status of this feature request. |
|
@AOrobator you should rarely if ever have to use "always exclude", that's only for things like weak references. LeakCanary cannot "ignore" a leak until it knows what leak this is. Then it'll show up as an "excluded" leak and that's as good as it gets. |
|
In the meantime, I believe we can come up with a fix that doesn't involve reflection, if someone is interested in having some fun. This leak is triggered when So one way to "clean this up" is to create a dummy view group, keep it detached, add ViewLocationHolder.MAX_POOL_SIZE children (32) to it, then call This may be expansive, it's worth measuring it. |
|
I've just quickly tried next code: And I still see this leak in the Leak Canary (I need a button now to trigger the analysis to not click app to pass threshold). My understanding - View has context as a constructor parameter, this still leak activity since I will use current activity to construct views. |
|
@emartynov The button (notification) will be coming in the next alpha :) . In the meantime, press "home" (not back) and that will trigger the heap dump (triggers on app background) Edit: programmers make mistakes, whether they work at Google or not. Let's not pile on this, although I get the frustration :) . |
|
Also, do you have a short piece of code that reproduces the issue? |
|
@pyricau I think I found a pattern to reproduce the related issues: Open a DialogFragment from a Fragment, then press 'Current App' button (the Square button on NavigationBar), then press it again to bring everything to normal, then press 'Back' button until the App is closed. I can always reproduce this on my LG G7 running Android 9, but not always for AVD with Android 9 or 10. Details below: TestLeakFragment.ktclass TestFragment : Fragment() {
override fun onCreateView(
inflater: LayoutInflater,
container: ViewGroup?,
savedInstanceState: Bundle?
): View? {
val frame = FrameLayout(inflater.context)
frame.layoutParams = LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT)
val button = AppCompatButton(inflater.context)
button.layoutParams =
FrameLayout.LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT)
.also {
it.gravity = Gravity.CENTER
}
frame.addView(button)
button.text = "Click here!"
button.setOnClickListener {
TestDialogFragment().show(childFragmentManager, "test")
}
return frame
}
}
class TestDialogFragment : AppCompatDialogFragment() {
override fun onCreateView(
inflater: LayoutInflater,
container: ViewGroup?,
savedInstanceState: Bundle?
): View? {
return Button(inflater.context)
}
}activity_debug.xml<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
>
<fragment
android:id="@+id/debugContainer"
android:name="kohii.v1.sample.ui.debug.TestFragment"
android:layout_width="0dp"
android:layout_height="0dp"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"
/>
</androidx.constraintlayout.widget.ConstraintLayout>DevActivity.ktclass DevActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_debug)
}
}Logcat2019-11-07 22:30:35.828 18199-18199/kohii.v1.sample.dev D/LeakCanary: Installing AppWatcher
2019-11-07 22:30:44.265 18199-18199/kohii.v1.sample.dev D/LeakCanary: Watching instance of android.widget.Button with key e568fe83-59e8-4c79-91ae-a018a9e7df4e
2019-11-07 22:30:44.266 18199-18199/kohii.v1.sample.dev D/LeakCanary: Watching instance of kohii.v1.sample.ui.debug.TestDialogFragment with key 7cb87876-cf05-4b1a-b9ee-af12446c16e7
2019-11-07 22:30:45.773 18199-18199/kohii.v1.sample.dev D/LeakCanary: Already scheduled retained check, ignoring (app became invisible)
2019-11-07 22:30:45.777 18199-18199/kohii.v1.sample.dev D/LeakCanary: Watching instance of androidx.lifecycle.ReportFragment with key 7d73525c-097f-4664-aeb0-4fc5cc1390ce
2019-11-07 22:30:45.778 18199-18199/kohii.v1.sample.dev D/LeakCanary: Watching instance of kohii.v1.sample.DevActivity with key dd11f52d-374c-48e8-9c86-649ed295ccf5
2019-11-07 22:30:45.779 18199-18199/kohii.v1.sample.dev D/LeakCanary: Watching instance of android.widget.FrameLayout with key 820ab904-6a6e-4120-9b48-122dd4adf8b8
2019-11-07 22:30:45.781 18199-18199/kohii.v1.sample.dev D/LeakCanary: Watching instance of kohii.v1.sample.ui.debug.TestFragment with key 137ab2cd-5cc6-4d65-849b-c395ee8b6e61
2019-11-07 22:30:46.650 18199-18328/kohii.v1.sample.dev D/LeakCanary: Checking retained object because app became invisible
2019-11-07 22:30:46.651 18199-18328/kohii.v1.sample.dev D/LeakCanary: No retained objects
2019-11-07 22:30:49.294 18199-18199/kohii.v1.sample.dev D/LeakCanary: Already scheduled retained check, ignoring (found new object retained)
2019-11-07 22:30:49.295 18199-18328/kohii.v1.sample.dev D/LeakCanary: Checking retained object because found new object retained
2019-11-07 22:30:49.488 18199-18328/kohii.v1.sample.dev D/LeakCanary: Found 2 retained objects, which is less than the visible threshold of 5
2019-11-07 22:30:50.810 18199-18199/kohii.v1.sample.dev D/LeakCanary: Already scheduled retained check, ignoring (found new object retained)
2019-11-07 22:30:50.811 18199-18199/kohii.v1.sample.dev D/LeakCanary: Already scheduled retained check, ignoring (found new object retained)
2019-11-07 22:30:51.551 18199-18328/kohii.v1.sample.dev D/LeakCanary: Checking retained object because Showing retained objects notification
2019-11-07 22:30:51.759 18199-18328/kohii.v1.sample.dev D/LeakCanary: Found 6 retained references, dumping the heap
2019-11-07 22:30:51.795 18199-18328/kohii.v1.sample.dev D/LeakCanary: Removing 1 heap dumps
2019-11-07 22:30:57.226 18199-18350/kohii.v1.sample.dev D/LeakCanary: Analysis in progress, working on: PARSING_HEAP_DUMP
2019-11-07 22:30:58.484 18199-18350/kohii.v1.sample.dev D/LeakCanary: Analysis in progress, working on: FINDING_LEAKING_INSTANCES
2019-11-07 22:30:59.613 18199-18350/kohii.v1.sample.dev D/LeakCanary: Analysis in progress, working on: FINDING_PATHS_TO_LEAKING_INSTANCES
2019-11-07 22:31:05.526 18199-18350/kohii.v1.sample.dev D/LeakCanary: Analysis in progress, working on: FINDING_DOMINATORS
2019-11-07 22:31:05.575 18199-18350/kohii.v1.sample.dev D/LeakCanary: Analysis in progress, working on: COMPUTING_NATIVE_RETAINED_SIZE
2019-11-07 22:31:05.878 18199-18350/kohii.v1.sample.dev D/LeakCanary: Analysis in progress, working on: COMPUTING_RETAINED_SIZE
2019-11-07 22:31:05.907 18199-18350/kohii.v1.sample.dev D/LeakCanary: Analysis in progress, working on: BUILDING_LEAK_TRACES
2019-11-07 22:31:05.919 18199-18350/kohii.v1.sample.dev D/LeakCanary: Analysis in progress, working on: REPORTING_HEAP_ANALYSIS
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: HeapAnalysisSuccess(heapDumpFile=/storage/emulated/0/Download/leakcanary-kohii.v1.sample.dev/2019-11-07_22-30-51_803.hprof, createdAtTimeMillis=1573133465921, analysisDurationMillis=8696, applicationLeaks=[], libraryLeaks=[LibraryLeak(className=kohii.v1.sample.DevActivity, leakTrace=
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ┬
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ android.view.ViewGroup$ViewLocationHolder
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: NO (a class is never leaking)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ GC Root: System class
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ static ViewGroup$ViewLocationHolder.sPool
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ~~~~~
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ android.util.Pools$SynchronizedPool
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: UNKNOWN
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ Pools$SynchronizedPool.mPool
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ~~~~~
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ java.lang.Object[]
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: UNKNOWN
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ array Object[].[0]
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ~~~
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ android.view.ViewGroup$ViewLocationHolder
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: UNKNOWN
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ ViewGroup$ViewLocationHolder.mRoot
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ~~~~~
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ androidx.appcompat.widget.FitWindowsFrameLayout
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: YES (View.mContext references a destroyed activity)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ mContext instance of android.view.ContextThemeWrapper, wrapping activity kohii.v1.sample.DevActivity with mDestroyed = true
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ View#mParent is set
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ View#mAttachInfo is null (view detached)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ View.mWindowAttachCount = 1
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ FitWindowsFrameLayout.mContext
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ android.view.ContextThemeWrapper
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: YES (FitWindowsFrameLayout↑ is leaking and ContextThemeWrapper wraps an Activity with Activity.mDestroyed true)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ ContextThemeWrapper.mBase
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ╰→ kohii.v1.sample.DevActivity
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: Leaking: YES (ContextThemeWrapper↑ is leaking and Activity#mDestroyed is true and ObjectWatcher was watching this)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: key = dd11f52d-374c-48e8-9c86-649ed295ccf5
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: watchDurationMillis = 5981
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: retainedDurationMillis = 948
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: , retainedHeapByteSize=11812, pattern=instance field android.view.ViewGroup$ViewLocationHolder#mRoot, description=In Android P, ViewLocationHolder has an mRoot field that is not cleared in its clear() method. Introduced in https://github.com/aosp-mirror/platform_frameworks_base/commit/86b326012813f09d8f1de7d6d26c986a909d Bug report: https://issuetracker.google.com/issues/112792715), LibraryLeak(className=android.widget.Button, leakTrace=
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ┬
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ android.view.ViewGroup$ViewLocationHolder
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: NO (a class is never leaking)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ GC Root: System class
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ static ViewGroup$ViewLocationHolder.sPool
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ~~~~~
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ android.util.Pools$SynchronizedPool
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: UNKNOWN
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ Pools$SynchronizedPool.mPool
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ~~~~~
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ java.lang.Object[]
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: UNKNOWN
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ array Object[].[0]
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ~~~
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ android.view.ViewGroup$ViewLocationHolder
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: UNKNOWN
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ ViewGroup$ViewLocationHolder.mRoot
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ~~~~~
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ androidx.appcompat.widget.FitWindowsFrameLayout
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: YES (View.mContext references a destroyed activity)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ mContext instance of android.view.ContextThemeWrapper, wrapping activity kohii.v1.sample.DevActivity with mDestroyed = true
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ View#mParent is set
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ View#mAttachInfo is null (view detached)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ View.mWindowAttachCount = 1
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ FitWindowsFrameLayout.mChildren
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ android.view.View[]
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: YES (FitWindowsFrameLayout↑ is leaking)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ array View[].[0]
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ androidx.appcompat.widget.ContentFrameLayout
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: YES (View[]↑ is leaking and View.mContext references a destroyed activity)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ mContext instance of android.view.ContextThemeWrapper, wrapping activity kohii.v1.sample.DevActivity with mDestroyed = true
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ View#mParent is set
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ View#mAttachInfo is null (view detached)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ View.mWindowAttachCount = 1
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ ContentFrameLayout.mChildren
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ├─ android.view.View[]
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ Leaking: YES (ContentFrameLayout↑ is leaking)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: │ ↓ array View[].[0]
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: ╰→ android.widget.Button
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: Leaking: YES (View[]↑ is leaking and View.mContext references a destroyed activity and ObjectWatcher was watching this)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: mContext instance of android.view.ContextThemeWrapper, wrapping activity kohii.v1.sample.DevActivity with mDestroyed = true
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: View#mParent is set
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: View#mAttachInfo is null (view detached)
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: View.mWindowAttachCount = 1
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: key = e568fe83-59e8-4c79-91ae-a018a9e7df4e
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: watchDurationMillis = 7494
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: retainedDurationMillis = 2467
2019-11-07 22:31:05.924 18199-18350/kohii.v1.sample.dev D/LeakCanary: , retainedHeapByteSize=17473, pattern=instance field android.view.ViewGroup$ViewLocationHolder#mRoot, description=In Android P, ViewLocationHolder has an mRoot field that is not cleared in its clear() method. Introduced in https://github.com/aosp-mirror/platform_frameworks_base/commit/86b326012813f09d8f1de7d6d26c986a909d Bug report: https://issuetracker.google.com/issues/112792715)])
|
|
Anyone has any update about this leak. Google has locked the issue tracker thread and leak has been happening a lot on my app. :( |
|
I found the same problem in Android P |
pyricau
added a commit
that referenced
this issue
May 22, 2020
Related to #1081 Used the code from @jrodbx ([here](#1081 (comment))) to log whether the leak is happening, which worked after changing this: ``` adb shell settings put global hidden_api_policy_pre_p_apps 1 adb shell settings put global hidden_api_policy_p_apps 1 ``` Then I used the code from @eneim [here](#1081 (comment)) to reproduce the leak. The leak was not happening on the P emulator until I turned on talkback, then it immediately started happening.
pyricau
added a commit
that referenced
this issue
May 22, 2020
Uses the fix from @emartynov ([here](#1081 (comment))) except we use the application context instead of activity context to avoid reintroducing a leak. This effectively flushes the pool on activity destroy. Ideally, we'd do that on fragment as well, and pretty much any time a chunk of the view hierarchy changes.
|
Good news! I managed to reproduce the leak here: #1842 Then I applied a fix: d3769b1 and it's working! The next release of LeakCanary will include a separate artifact that can fix leaks for you, automatically, so ideally I can ship this fix as well. The main thing to figure out is when to apply it. Fragment destroy? Activity destroy? Every time a view is detached? |
|
big thanks to @jrodbx (for the reflection code which I used to quickly detect if there was a leak / if the fix was working), @eneim for the repro code, and @emartynov for the almost working fix that involves no reflection. |
|
@pyricau, that was a big surprise for me this morning. I completely forgot about this and super busy with my current job change that I don't participate in the open-source much (unfortunately). To be honest, the biggest part of this code I took from @swankjesse somewhere online and just a bit improved it later (if I remember it correctly). Thank you again for such a great library. Looking forward to the new release. |
pyricau
added a commit
that referenced
this issue
May 29, 2020
Uses the fix from @emartynov ([here](#1081 (comment))) except we use the application context instead of activity context to avoid reintroducing a leak. This effectively flushes the pool on activity destroy. Ideally, we'd do that on fragment as well, and pretty much any time a chunk of the view hierarchy changes.
pyricau
added a commit
that referenced
this issue
Jun 4, 2020
Uses the fix from @emartynov ([here](#1081 (comment))) except we use the application context instead of activity context to avoid reintroducing a leak. This effectively flushes the pool on activity destroy. Ideally, we'd do that on fragment as well, and pretty much any time a chunk of the view hierarchy changes.
|
👋🏻 |
Martinvlba
pushed a commit
to KekHunterOS/KekHunter
that referenced
this issue
Oct 30, 2020
…freeing them would cause null exception when press back button to jump back to previous fragment. But the app will reports memory leaks when the app is terminated, seems there is still no any good looking solutions to address this issue. See square/leakcanary#1081
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm testing my app with the new leak canary and on different devices (as well as virtual devices).
everything looks fine on all devices except one device which is the only one running Android 8.
the analyzing process looks fine but whenever it finishes it shows a few leaks (which other devices won't show!).
every time I check the trace I end up either with ReportFragment or InputMethodManager.
is anything actually leaking? is this an excluded leak?
thanks in advance
The text was updated successfully, but these errors were encountered: