Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Android 17] Early observations: JIT thread pool crash on attach and JNI transition frame aborts

Aperta
#411 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
android, java, javascript

Direzione di ricerca

The payload names no file in this repository; the crashes are in ART internals (art::jit::Jit::CreateThreadPool) and in the JNI transition check. Start by reproducing the Java.use hooks on android.webkit.WebView $init and android.os.Binder attachInterface on an API 37 device or emulator, then gather the tombstone. Done would mean a hook pattern that survives on API 37 with a stated cause, which needs Android runtime knowledge and a maintainer decision on scope.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Ran into a couple of quirks while testing Frida 17.21.0 on Android 17 (API 37, build CE2A.260420.019). Opening this up to share logs and reproduction details in case they're useful as A17 support gets fleshed out.

1. SIGSEGV in art::jit::Jit::CreateThreadPool during attach
  • Behavior: When attaching frida-server early during process launch, ART intermittently segfaults inside art::jit::Jit::CreateThreadPool.
  • Observations: Appears to be a race between ptrace attachment and JIT thread pool initialization. Disabling JIT before launching or attaching avoids the crash on our end:
    adb shell setprop dalvik.vm.usejit false
    
    Not sure if there's a cleaner synchronization hook or if this is primarily visible on emulator timing, but wanted to mention it.
2. Runtime abort: JNI transition frame error
  • Behavior: Hooking native constructor stubs or Binder entrypoints causes ART to abort the process:
    art E ... JNI transition frame error
    
  • Reproduction cases we saw:
    • Replacing $init on native classes:
      Java.use('android.webkit.WebView').$init.implementation = ...
    • Hooking Binder interface registration:
      Java.use('android.os.Binder').attachInterface.implementation = ...
  • Observations: Looks like A17 might have tightened up stack validation or frame accounting around native-to-managed transitions. Replacing these native stubs with JS trampolines seems to trigger that transition check.
  • Current workaround for us: Steered our scripts away from hooking $init and Binder.attachInterface directly on API 37, targeting higher-level callers or concrete factory methods instead.

Happy to pull more tombstones or test proposed patches if anyone is digging into A17 support.

Lingua principale
JavaScript
Stelle
413
Fork
174
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di frida/frida-java-bridge

Tutte le issue di frida/frida-java-bridge

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.