Thank you! Why only do this for arm64? And what is the exact issue here, is it that we're passing an empty envp, and there's code assuming there's at least one element before the terminator?

Thanks for taking a look!

I kept this arm64-only because that is where I have a reliable repro and validation: iOS arm64e, attaching to a target that previously crashed during early initializer execution. I have not verified the same failure mode on the x86 or
32-bit ARM Darwin mapper paths. I noticed those paths also pass empty_strv as envp, so if the intended mapper contract is “no environment”, I’m happy to update the PR to make those pass NULL as well for consistency.

The issue I observed does not look like code iterating an empty envp and assuming there is at least one element before the terminator.

The crash evidence points to the non-NULL pointer value itself leaking through the arm64 initializer ABI. The mapper was calling initializers with:

x0 = 0
x1 = empty_strv
x2 = empty_strv
x3 = apple_strv
x4 = 0

In the failing process, the initializer-triggered path entered an Objective-C/framework path. The crashing frame was objc_msgSend with selector setSymptomsStatus:, and the receiver was the mapper-owned empty_strv address inside
the Frida payload. In other words, the synthetic non-NULL envp pointer was later interpreted as an Objective-C object receiver. Since it is non-NULL but not an object, objc_msgSend crashed.

Passing NULL for x2/envp avoids exposing this mapper-owned address. With this change I rebuilt an iOS arm64e server and repeatedly attached to the previously failing target after restarting it; all attempts succeeded and no new
crash report was generated.