The specific line is the guard statement, so yeah, I was going to try to break it up. However, I disassembled at one point:          * At +521, %r13 is 0x0.                                                                                                        * Redirector.o[0x8c70] <+512>:  callq  0x8c75                    ; <+517> [inlined] Redirector.flowSets.getter : Swift.Dictionary<Foundation.UUID, FlowData> + 27 at Redirector.swift:651:43                                                                                                           * Redirector.o[0x8c75] <+517>:  movq   (%r14,%rbx), %r13                                                                       * Redirector.o[0x8c79] <+521>:  cmpq   $0x0, 0x10(%r13)                                                                        * Redirector.o[0x8c7e] <+526>:  je     0x8d35                    ; <+709> at Redirector.swift:651:43 So I assume that %r13 has self.flowSets[id] (rather than id). For some reason, however, I didn't disassemble enough to have %r14 and %rbx annotated.

Ok, that's what I thought. 😄 (And what I am doing.)

We use cmake, so it was a bit more difficult -- and CircleCI, so I had to make sure the dsym files got archived. Did that. Re-confirmed it's this code:         guard let flowData = self.flowSets[id] else {             os_log(.error, log: Self.log, "Could not find flow %{public}@", id.uuidString);             completion(RedirectorError.flowNotFound)             return } id is a UUID; self.flowSets is private var flowSets : [UUID : FlowData] = [:] (where FlowData is a simple class wrapping some flow-related information). This particular method is invoked via XPC from a daemon, with a signature of func handleTCPData(_ id: UUID, data: Data?, completion: @escaping (_: Error?) -> Void). The daemon code is in ObjC++, and it checks to ensure that the UUID is non-nil. So I have no idea why it is segfaulting!

Ah! NEFilterDataProvider! As I said, I figured out that it's the level 2 ethernet, not level 1. I get tunnel vision sometimes.

Ah. If it's just struct ether_header {         u_char  ether_dhost[ETHER_ADDR_LEN];         u_char  ether_shost[ETHER_ADDR_LEN];         u_short ether_type; } __packed; then it makes sense.

I meant "copying the signing command." :)

Also, is there a better way of getting the line number from the address than using lldb or objdump to disassemble with lines? ;) It's hit and miss, unfortunately.

I tried thread sanitizer, unfortunately it fails too much on the 3rd party C++ code the project uses. The Swift method in question here has a closer which itself has a closure.

Oh, and the textified version. next-crash.txt

Here's the raw-ish IPS. I'm sure concurrency is the problem. next.ips

None of the arguments is ever modified by something else; the most that happens is that references are added and removed. sigh.

Now, this still leaves me wondering how to combine them into a single bundle. I mean, I know how to script the part where I lipo the various parts together, but I'm not sure how to get the proper signing done, other than copying the output of xcodebuild. We can have separate distributions for now (until and unless Apple lets me use the Endpoint Security Framework for real, we can't be feature-complete, or at least feature-parity with Windows, anyway).

Over, on twitter, Alexander Neumann (@Iluinrandir) gave me the solution. I used env PATH=${HOME}/vcpkg-arm64:${PATH} cmake -G Xcode .. -DVCPKG_HOST_TRIPLET=x64-osx -DVCPKG_TARGET_TRIPLET=arm64-osx -DCMAKE_TOOLCHAIN_FILE=${HOME}/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_OSX_ARCHITECTURES=arm64 -DMACOS_BUILD_RELEASE=ON to create the xcodeproj, and then time cmake --build . --config Release -- -allowProvisioningUpdates to build. And... I ended up with arm64 executables that work on my M1 MBP. I'm not sure if the -DCMAKE_OSX_ARCHITECTURES=arm64 is necessary or not.

Cmake, not make. And vcpkg. Alas. I am very familiar with using Apple‘s tool, including Xcode and make, to build universal binaries of all sorts. I have been for a while. It’s this third-party stuff I need help with.

Sigh and alas.