Swift, XPC, and... segmentation faults?

Swift helps avoid memory management bugs but it can’t completely prevent them. There are two big holes in the Swift’s memory management defences:

• Unsafe constructs, including any calls to a C-based language, which means most of the OS

• Concurrency

XPC code can is subject to both (-:

As to what’s happening in your specific case, it’s hard to say without more info. To start, please post a full crash report. See Posting a Crash Report for advice on how to do that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

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

Oh, and the textified version.

I'm sure concurrency is the problem.

In that case, have you tried TSan?

Looking at your crash report, I see this:

Thread 4 Crashed::  Dispatch queue: com.apple.NSXPCConnection.user.endpoint
0   com.kithrup.MyExt.NExt … NExt.handleData(_:data:completion:) + 610

+ 610 is a long way in to your method. If you symbolicate the log, what line does that map to? And what’s the code on that line?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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.

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.

Hmmm, that’s not a good sign. If you temporarily stub out that library, do you still see these crashes?

there a better way of getting the line number from the address

Most of the time that happens automatically, presuming you have your .dSYM files set up correctly. For all the gory details, see Adding Identifiable Symbol Names to a Crash Report.

Oh, one other hint: For testing purposes you can implement a loopback XPC listener, allowing you to stress test your XPC subsystem in a sensible environment, like an XCTest. For info on how to do that, see TN3113 Testing and debugging XPC code with an anonymous listener.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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!

Which specific line does it point to?

One trick here is to break the statements up into multiple lines to help isolate it. For example:

let flowDataQ = self.flowSets[id]
guard flowData = flowDataQ else {
    …

A completely different approach is to enable core dumps on your daemon so that, when it crashes, you have something to debug.

Also, can you post a full crash report here. See Posting a Crash Report for advice on how to do that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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.