mirror of
https://github.com/StikDebug/StikDebug.git
synced 2026-10-16 12:30:29 +00:00
42951c6e10
The experimental "Hold App Alive in Background" mode attached the debugger (setting CS_DEBUGGED) but never ran the app's assigned JIT script. On TXM / iOS 26+ devices JIT is not enabled merely by attaching: the app requests executable memory at runtime via `brk #0xf00d` syscalls that the debugger must service, which is exactly what the JIT script does in its breakpoint loop. Without the script those syscalls went unhandled, so the app trapped and hung (or JIT silently failed) on its first JIT call -- "the JIT script doesn't run when attaching to an app." Thread the same JIT-script callback the normal debug path uses through the hold flow: - HomeView.startKeepAlive resolves the app's preferred script (gated on hasTXM, exactly like startJITInBackground) and passes it down. - BackgroundAliveManager.start and JITEnableContext.keepAppAlive forward it to holdDebugSession. - holdDebugSession, when a script is present, runs it (the script does its own vAttach + JIT enable + continue and services the app's JIT syscalls for as long as the app uses JIT, keeping the app alive under the debugger). When absent it keeps the previous attach-and-hold behavior for older devices where CS_DEBUGGED alone enables JIT. The normal (non-hold) JIT path is unchanged. Known limitation: for an app whose script runs continuously, the hold ends when the app is closed (matching the normal flow, which likewise cannot interrupt a running script); the Stop button fully applies to the no-script hold path. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013DNqCsHShA4yNqgZ6ZZQy3 |
||
|---|---|---|
| .. | ||
| App | ||
| Assets.xcassets | ||
| Core | ||
| Device | ||
| Features | ||
| idevice | ||
| JSSupport | ||
| Scripts | ||
| Services | ||
| StikDebug.icon | ||
| Support | ||
| Views | ||
| Info.plist | ||
| StikDebug.entitlements | ||