[pyricau]

LeakCanary and Shark Dive described an object in two ways. LeakCanary's inspectors wrote labels, each spelling its values its own way: Thread name: 'main', Fragment.mTag=home, mRunning = true. Shark Dive read strings, threads, arrays and bitmaps itself, into an ObjectContent of its own. Now an inspector calls ObjectReporter.addSyntheticField(name, value) for each value it reads. A leak trace prints it like a field, Thread.name = "main", and Shark Dive prints the same line.

Four commits, meant to be read one at a time:

1. Report what object inspectors read as synthetic fields.
   • SyntheticField(name, value), ObjectReporter.addSyntheticField() and ObjectReporter.syntheticFields, LeakTraceObject.syntheticFields.
   • Every built-in inspector that read a value reports a synthetic field. The inspector formats the value: a string quoted and escaped, another object as android.os.Handler@0x12c0a6b8, a constant by name, as in TYPE_TOAST (2005).
   • New STRING, ARRAY and BITMAP inspectors, in the default lists.
   • LeakCanary's two leak trace UIs print the synthetic fields before the labels.
   • LeakTraceObject's serialVersionUID is bumped.
2. Draw Shark Dive's objects from the inspectors' synthetic fields. ObjectContent is gone, and nothing in Shark Dive picks a field out by name. The details panel and a path print one field per line. A row of a list, a leaking object and the card at the pointer join them on one line. The agent JSON has a syntheticFields object keyed by name.
3. Link a binder stub to a page on fixing what it holds. The verdict reason is X is a binder stub. The label is Look for the leak in what X holds, see https://square.github.io/leakcanary/binder-stubs/, and docs/binder-stubs.md is that page.
4. Say how far Message.when is from the heap dump in a larger unit too. Message.when is 7200000 ms (2 hours) before the heap dump.

A leak trace now ends like this, from shark/shark-android/src/test/resources/gcroot_unknown_object.hprof:

├─ androidx.fragment.app.Fragment[] array 0x13b398a8
│    Verdict: Expected (DvFragment↓ is expected)
│    length = 6
│    ↓ Fragment[3]
├─ com.jumio.qa.view.DvFragment instance 0x13aaa748
│    Verdict: Expected (Fragment.mLifecycleRegistry.state is CREATED)
│    Fragment.mTag = "android:switcher:2131296475:3"
│    ↓ DvFragment.mRoot
│                 ~~~~~
╰→ android.widget.ScrollView instance 0x13aaa868
​     Verdict: Stuck (ObjectWatcher was watching this)
​     Retaining 5.8 kB in 89 objects
​     KeyedWeakReference.key = "e4157a1a-b2ce-4775-9520-d5cfab82e6df"
​     KeyedWeakReference.watchDurationMillis = 75359
​     KeyedWeakReference.retainedDurationMillis = 70357
​     View.mWindowAttachCount = 1
​     View not part of a window view hierarchy
​     View.mAttachInfo is null (view detached)
​     mContext instance of com.jumio.qa.MainActivity with mDestroyed = false

API

• LeakTraceObject has syntheticFields as a new last constructor parameter with a default. Its <init> and copy signatures change, and Kotlin source compiles unchanged. ⚠️ in the changelog.
• Everything else in shark.api and shark-android.api is new API.

Left as they were

• Verdict reasons are still strings.
• How far Message.when is from the heap dump stays a label, next to the Message.when synthetic field.
• The CONTEXT_FIELD lines, such as mContext instance of … with mDestroyed = false, stay labels.

🤖 Generated with Claude Code

[pyricau]

LeakCanary reports binder stubs as expected. The objects a stub holds keep their own verdict, and the leak is usually one of them.

it's not clear that this word has special meaning. Also the second sentence isn't super clear. "The leak is usually one of them" is pointing to it a bit too much.

If a leaktrace contains a binder stub on its path, LeakCanary marks that binder stub as "Expected", i.e. binder stubs are expected to stay in memory potentially forever. Unfortunately, developers often don't realize that, and forget to clear out the fields of binder stub objects when they stop being used, which is often a cause of leak.

[pyricau]

🤖 Rewrote it along the lines of your version: the stub stays in memory until the other process collects its proxy, potentially forever, and LeakCanary gives it the verdict Expected. A second paragraph says developers often forget to clear a stub's fields once it's no longer needed, and that this is a common cause of leaks. The changelog bullet said the same sentence, so I changed it too. Folded into the binder stub commit: d64715e

[pyricau]

iirc object inspectors have an abstract method to find leaking objects, which delegates to inspect when not implemented. I think here we want to override it and just return nothing, right? To avoid running this inspector which only does synthetic fields . Unless that's already the default behavior, which it probably is otherwise this would be a problem with other inspectors that don't set a verdict.

[pyricau]

🤖 That's already the default, so I left this inspector as it is. The hook is leakingObjectFilter, which is null unless an inspector overrides it (ObjectInspectors.kt#L162), and createLeakingObjectFilters drops the nulls with mapNotNull (L183-L187). THREAD, STRING and ARRAY have no filter, so leak finding never runs them. They only run on the objects of a path once a leak trace is being built.