epic
epic

Reputation: 1443

what are LIBRARY LEAKS in leakcanary?

in leakcanary sometimes i am getting leaks reported as "Library leaks"

 HEAP ANALYSIS RESULT
    ====================================
    0 APPLICATION LEAKS

    References underlined with "~~~" are likely causes.
    Learn more at https://squ.re/leaks.
    ====================================
    1 LIBRARY LEAKS

    Library Leaks are leaks coming from the Android Framework or Google libraries.

    Leak 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
    66264 bytes retained by leaking objects
    Signature: 64becd25d6156daa91df6572a75b6a28ddb1
    ┬───
    │ GC Root: System class

at the leakcanary website it says:

LibraryLeak at leakcanary website

LibraryLeak

data class LibraryLeak :Leak

A leak found by HeapAnalyzer, where the only path to the leaking object required going through a reference matched by pattern, as provided to a LibraryLeakReferenceMatcher instance. This is a known leak in library code that is beyond your control.

is it really out of my control?

might there be something i did to cause it?

Is there anything i can do to prevent it?

leakcanry sometimes places a link to report this memory leak but i don't see any response, is it something that android normally working on? if so, how such issues normally solved and how to keep track?

if indeed there is nothing i can do to solve or prevent it, is there a way i can ask leakcanary to ignore LIBRARY LEAKS?

Upvotes: 1

Views: 1684

Answers (1)

Pierre-Yves Ricau
Pierre-Yves Ricau

Reputation: 8349

That's a great question, and in fact this should be better documented so I created an issue to track that: https://github.com/square/leakcanary/issues/1773

is it really out of my control?

Yes and no. Typically this means the leak isn't caused by a bug in your code or using an API incorrectly, it's caused by a bug in either Android X or the Android SDK. That being said, it's not always out of your controls, there can be tricks / hacks to work around leaks.

might there be something i did to cause it?

The ViewLocationHolder in Android P is an unfortunate bug that happens.. when you use views. So yeah, you didn't really do anything special.

Is there anything i can do to prevent it?

Potentially but no one has come up with a clear hack to work around it yet.

leakcanry sometimes places a link to report this memory leak but i don't see any response, is it something that android normally working on? if so, how such issues normally solved and how to keep track?

Not sure what you mean here. If you mean that the link to the bug report (https://issuetracker.google.com/issues/112792715) stopped working, yes that's because Google decide to prevent access.

if indeed there is nothing i can do to solve or prevent it, is there a way i can ask leakcanary to ignore LIBRARY LEAKS?

There's no way for LeakCanary to know whether a leak is a library leak or not prior to dumping the heap and doing the analysis. It's important to notify developers that the analysis is done (even if it only found a library leak and no app leak) because otherwise they wonder what happened to the analysis.

Upvotes: 4

Related Questions