Re: Crash when using closures on iOS+arm64

[Russell Keith-Magee <russell@keith-magee.com>]

Hi Simon,

On Fri, May 15, 2015 at 1:27 AM, Simon Frost <simon.frost@realvnc.com> wrote:
> Hi,
>
> I’ve been attempting to use closures across 32-bit, 64-bit and simulator builds of an iOS project but I consistently see a crash on the arm64 build when the closure is executed. This can be reproduced in a stripped down Xcode project by simply copying the code from the “closure_simple.c” unit test into the iOS application’s main.m file. I’ve seen this issue on both the latest code from master and the v3.2.1 tagged release.
>
> Specifically I see an EXC_BAD_ACCESS exception when trying to call the executable address pointer populated by ffi_closure_alloc. Somewhat interestingly I see that the executable address (out param) and the writeable address (return value) are set to the same value after calling ffi_closure_alloc on arm64, whereas they have different values on armv7. This may be a red herring though, as I also noticed they also have the same value when running in the i386 simulator where the code works correctly.
>
> All other libffi functionality appears to work fine on arm64, the only issue appears to be calling closures. Can anyone shed any light on this, or give me any pointers as to how this could be resolved? Unfortunately I’m not well enough versed in the lower levels of libffi to look into fixing this myself.

Yes, I've seen similar problems; master has *less* problems than the
tagged release from my testing, but there are still some edge cases
that don't work.

As for fixing it - I'm in the same boat as you. I can provide test
cases that demonstrate failures, but I have no idea how to fix those
problems. Unfortunately, it looks like there aren't many people around
who have an interest in iOS *and* know how the internals of libffi
work. The current master code doesn't even *compile* for ARMv7 [1][2],
but I haven't been able to shake out anyone who is able to address the
problem.

[1] https://github.com/atgreen/libffi/issues/181
[2] https://sourceware.org/ml/libffi-discuss/2015/msg00053.html

Yours,
Russ Magee %-)