Madeira v0.1.3 — x18-derived TEB access crash (iPhone 17 Pro Max, iOS 27.0)

Environment

| -- | -- Madeira | v0.1.3 (released 2026-10-03), Madeira-0.1.3.ipa, SHA-256 verified Device | iPhone 17 Pro Max (iPhone18,2), iOS 27.0 (24A437), 11.6 GB RAM Install | Sideloadly, free Apple ID, drop_plugins=0 (app extension kept) JIT | Built-in StikJIT (MadeiraJITHelper), CS_DEBUGGED flag: SET (flags=0x32003005) Tunnel | LocalDevVPN 1.3.0 + StosVPN 1.2.1, vpn-interface=1, connected via utun5 10.7.1.1 Memory | address-map=[0x104848000,0x7180000000) 454GB, JIT pool 896 MB

With FEX_TSOENABLED=0 the faulting block is byte-for-byte the same (cb0a022a d356fd4a b400006a f9405f91 91500231 1000008a ... 52800000 [3d800100 ...]), so the trigger is not tail-call optimisation.

Question

Is there a way to get a build with the #267 x18 fixes (the madeira-bcd build, or a v0.1.4 release)? The public v0.1.3 IPA cannot run any game that touches a TEB-derived pointer, and rebuilding from source needs the unpushed submodule forks plus an LLVM-for-iOS toolchain.

Attached

Full madeira-log.txt (4 MB) for the Billie's Wheelie run, including the [x18-decline], [av-detail], [teb-tsd], [JITPOOL_RIP] and [x18-patch] sections.

Activity

intraducine3d ago

I checked the source boundary before closing related reports. #267 is merged and is present in main, but that alone does not establish that this report is fixed.

The words in the report decode as 0x3d800100: str q0, [x8], 0x3d800500: str q0, [x8, #16], and 0x52800000: mov w0, #0. The faulting write is a 16-byte vector store. The immediately preceding instruction does not compute x8 from x18. A zero x18 therefore does not by itself show that the NULL x8 came from the TEB.

I am keeping this issue open. The pointer origin in the FEX-generated block still needs a trace on a build that includes #267. The missing public build/nightly request is also tracked in #3. I am not merging this report into #249 or calling it fixed by #267.