[Kolektori]

Fixes #387.

On Android 16 (e.g. build BP4A.251205.006, com.android.art@361302280) the process crashes with a NULL dereference in art::CodeInfo::DecodeGcMasksOnly during a GC stack walk whenever a replacement ArtMethod is on some thread's stack when the collector runs. The reporter's backtrace in #387 shows the fault driven by art::gc::collector::MarkCompact::RunPhases → VisitRoots → StackVisitor::WalkStack → DecodeGcMasksOnly.

Two A16 libart.so changes together break the GC synchronization machinery in ensureArtKnowsHowToHandleReplacementMethods and instrumentArtGarbageCollection:

1. libart.so is now stripped — .symtab is gone but the library retains a .gnu_debugdata section (LZMA-compressed mini-debuginfo). Module.findSymbolByName reads .dynsym + .symtab and so returns null for Heap::CollectGarbageInternal and ConcurrentCopying::CopyingPhase on A16, silently skipping the hook install. Module.enumerateSymbols() does parse the mini-debuginfo, so the symbols are still reachable that way.

2. A16 defaults to Concurrent Mark Compact (CMC) instead of Concurrent Copying. Even if we resolve ConcurrentCopying::CopyingPhase, it never fires under CMC, so replacement ArtMethods are never re-synchronized after compaction. MarkCompact::RunPhases is the CMC lifecycle-event equivalent.

Changes

• Add a small resolveDebugdataSymbol(module, name) fallback that lazily caches Module.enumerateSymbols() per module, and plumb it into temporaryApi.find as a last resort after findExportByName / findSymbolByName. Same plumbing restores Heap::CollectGarbageInternal resolution transparently for all ART-symbol callers.
• Reroute the two raw art.findSymbolByName(...) call sites in instrumentArtGarbageCollection and instrumentArtFixupStaticTrampolines through api.find so they pick up the mini-debuginfo fallback.
• When CopyingPhase is inlined (also seen on A16+), fall back to ConcurrentCopying::RunPhases as the hook point — one level up in the same phase-driver function.
• Additionally hook MarkCompact::RunPhases with the existing artController.hooks.Gc.copyingPhase callback. The callback is collector-agnostic — it just synchronizes entrypoints at a "world is consistent again" lifecycle point — so reusing it for CMC is correct. Both hooks can coexist; only the active collector dispatches its phase.

Net diff: lib/android.js +38 / −4.

Testing

Reproduced #387 on a Cuttlefish x86_64 guest running aosp-android-latest-release (build 15150359, API 36, same libart BuildId class as the Pixel 7 reporter's build). Unpatched 7.0.13: HeapTaskDaemon SIGSEGV within seconds of attaching a .implementation hook to any hot constructor (e.g. java.net.URL.<init>(String) or java.io.File.<init>(String)).

With this patch applied, the following hook set runs to completion simultaneously on the same target for a full 90s analysis window:

• .implementation swaps on java.net.URL.<init>(String) and java.io.File.<init>(String)
• .implementation swaps on all 17 java.lang.StringFactory.newString* overloads
• Interceptor.attach on art::mirror::String::AllocFromModifiedUtf8 (3 overloads) and AllocFromUtf16
• Interceptor.attach on libc __system_property_get, __system_property_find, open, fopen*, freopen*, stat
• Interceptor.attach on libdl dynamic-loader exports
• Interceptor.attach on libart/libdexfile dex-retrieval paths

Observed: zero tombstones, no DecodeGcMasksOnly frames, full MITM / logcat / media / trace artifact set collected, hooks actively firing (600+ __system_property_get rewrites, 121 File.<init> callbacks, 60 MessageDigest callbacks in one run).

Notes

• No behavior change on pre-A16 builds: the new MarkCompact lookup simply returns null there via api.find, and the mini-debuginfo fallback is a no-op when findSymbolByName already succeeds.
• WeakMap-keyed symbol cache so entries die with the module.
• Kept Thread::RunFlipFunction hook as-is — still exported, still correct on CC builds.

[oleavr]

Thanks for the detailed write-up.

Before merging I want to understand the findSymbolByName vs enumerateSymbols split, because in Gum both go through the same gum_elf_module_enumerate_symbols, which already falls back to .gnu_debugdata when .symtab is missing. So in principle they shouldn't disagree.

A few questions:

1. Which frida / frida-server version on the A16 device? The mini-debuginfo fallback landed in gum 8ed32c4d (Dec 2024), the dynsym fallback in 01eadbff (Mar 2026).
2. Does findSymbolByName('libart.so', '_ZN3art2gc4Heap22CollectGarbageInternalENS0_9collector6GcTypeENS0_7GcCauseEbj') start working after an
   enumerateSymbols() pass on the same module? That would point at a state/ordering bug in Gum.
3. readelf -S on the device's libart.so — which of .symtab / .dynsym / .gnu_debugdata are present?

If it's a Gum bug I'd rather fix it there.

[radubogdan2k]

Checked on Samsung S25 / Android 16 BP4A.251205.006 (Snapdragon 8 Elite, arm64) — applied this patch on top of frida-java-bridge@7.0.13

Summary
The patch as it stands is necessary but not sufficient on this build:

1. The two findSymbolByName → api.find swaps and the new .gnu_debugdata fallback are 100% required — without them none of the existing GC hooks (Heap::CollectGarbageInternal onLeave, Thread::RunFlipFunction onEnter, ConcurrentCopying::CopyingPhase onLeave) ever attach on this build. libart's .symtab is stripped; only .gnu_debugdata carries the internal symbols. Confirmed by nm /tmp/libart.dbg after objcopy --dump-section .gnu_debugdata=… + xz -d.
2. The MarkCompact::RunPhases hook with onLeave only does not prevent the documented DecodeGcMasksOnly+0x?? → ReferenceMapVisitor::VisitFrame+0x?? → CheckpointMarkThreadRoots::Run crash. Crashes consistently within RunPhases's call to CheckpointMarkThreadRoots, before onLeave ever fires. Tried adding onEnter with on_leave_gc_concurrent_copying_copying_phase (the access-flags-only sync) and separately with the full synchronize_replacement_methods (access flags + quick_code rewire) — neither changed the symptom. The stack walker reads the OatQuickMethodHeader regardless of replacement-method access-flags state on BP4A.
3. Root cause from disassembly (art::CodeInfo::DecodeGcMasksOnly, offset +48):
   ldr w8, [x0] ; first instruction that touches the OatQuickMethodHeader
4. Crashes with fault addr 0x0 because on_art_method_get_oat_quick_method_header in the existing CModule returns NULL for replacement methods. Older ART checked for null; BP4A's DecodeGcMasksOnly does not — it unconditionally dereferences.
5. Symptomatic workaround that does eliminate this crash: from the user agent, Interceptor.attach DecodeGcMasksOnly's entry; in onEnter, if args[0].isNull(), swap to a Memory.alloc(4096) zero page. Function then reads zeros, computes x0 - *x0 = x0, calls the CodeInfo decoder on a zeroed blob → returns "no GC roots" → caller is happy. No longer hits DecodeGcMasksOnly. (This obviously belongs inside the bridge, not the agent — flagging in case it informs a better fix at the on_art_method_get_oat_quick_method_header level. The proper fix is presumably for on_art_method_get_oat_quick_method_header to return a pre-allocated safe-empty header instead of NULL.)
6. A second, structurally similar crash is hiding behind the first one on this build:
   #00 art::JValue art::InvokeWithVarArgs<_jmethodID*>(...)+148/+156/+168 Cleanup & a few bug fixes regarding method re-implementation #1 art::JNI::CallStaticObjectMethodV+120 Process Crash when replacing the implementation of any Java method using ART #2 <app's own JNI code calling CallStaticObjectMethod>
7. Fault addresses are a mix of null+small offsets (e.g. 0x68) and high-bits-garbled pointers (e.g. 0x0042164070379c40, 0xb091bb17, 0x0000000df00640fa) — type-confusion pattern. Triggered on background worker threads (AppShared-Cpu-*, AppStartUp-1) by the app's own native code doing routine (*env)->CallStaticObjectMethod(...).

[serkan-ozal]

Hi all, is there any update on this issue/fix? This is also blocker for us at IronBee

[eric-sabe]

Took a look at @oleavr's question regarding Gum's .gnu_debugdata handling on live A16 and A17 setups with Frida 17.21.0. A few observations from the trenches that might help:

1. Gum .gnu_debugdata resolution:
   Tested findSymbolByName on libart.so for debug-only symbols before and after calling enumerateSymbols(). In our tests, findSymbolByName resolved the symbol pointer immediately on the first call (matching what enumerateSymbols() found). It looks like Gum commit 01eadbff is already handling mini-debuginfo lookup natively, so the JS-side caching logic in this PR might be redundant on current Frida builds.

2. Generational CMC (YoungMarkCompact):
   While poking at CMC behavior on A16/A17, we noticed libart.so exposes both:

   • _ZN3art2gc9collector11MarkCompact9RunPhasesEv
   • _ZN3art2gc9collector16YoungMarkCompact9RunPhasesEv
     In our runs, hooking only full MarkCompact seemed to leave replacement methods vulnerable when young-gen GC sweeps ran, resulting in sporadic SEGV_MAPERR crashes at fault addr 0x10 during JNI calls. Hooking YoungMarkCompact::RunPhases as well seemed to prevent those faults.

3. Seconding @radubogdan2k on the DecodeGcMasksOnly crash ([Android 16] App crashes during Garbage Collection when Frida is attached (Build BP4A.251205.006) #387):
   Disassembling art::CodeInfo::DecodeGcMasksOnly from the A16/A17 images shows:

   • arm64 (offset +48): ldr w8, [x0]
   • x86_64 (offset +57): mov (%rsi), %rax
     The walker appears to blind-dereference the method header pointer. In lib/android.js CModule, on_art_method_get_oat_quick_method_header returns NULL for replacement methods:

   static OatQuickMethodHeader *
   on_art_method_get_oat_quick_method_header (gpointer method, gpointer pc)
   {
     if (is_replacement_method (method))
       return NULL;
     return get_oat_quick_method_header_impl (method, pc);
   }

   Older ART runtimes seemed to tolerate NULL here, but on A16+, a GC checkpoint while on a replaced method results in an immediate crash at 0x0.

   Wondering if it might make sense for on_art_method_get_oat_quick_method_header to return a pointer to a static dummy OatQuickMethodHeader encoding 0 roots rather than NULL? As a quick proof-of-concept in our agent, catching DecodeGcMasksOnly and supplying a zeroed page when null kept our test suite completely stable on A16.