Greetings everybody.
I've spent a few hours trying to get to the bottom of this and I'm all out of ideas. I have an application that interfaces with a native C library using a Swift wrapper. For architectural reasons, all calls to that library's code must be done in its worker threads.
To solve this, all of our swift wrapper functions create closures that are then passed to the library's worker system. Along the following lines:
public func doSomeWork(withConfig config: LibConfig, andResult result: @escaping ResultCallback) {
let cb: @convention(c) (UnsafeMutableRawPointer?) -> Void = { slotPtr in
// do some work
}
lib_run_work(cb)
}
This setup is used in 30+ places and none of them cause any issues, except for one of the closure callbacks. (slotPtr is used for reading and writing additional information for the command from a thread-safe array, this works fine in all other cases as well).
The one that causes the problem generates the following crash report via Crashlytics (unfortunately, I've never been able to replicate it locally so far to get a full crash report).
Crashed: Thread #1
EXC_BREAKPOINT 0x0000000100ff7878
Crashed: Thread
0 MyApp 0x1f878 closure #1 in LibStack.doSomeWork(withConfig:andResult:) + 4330895480 (LibStack.swift:4330895480)
1 MyApp 0x21761c timer_cb + 4332959260
Now, the closure that is referenced is ~30 LOC, none of which contain any obvious issues such as force-unwrapping optionals, though we're interacting with the C library and therefore unsafe memory directly.
The crash happens at 0x0000000100ff7878 (which is 4330895480) as listed in the last stack trace frame. But how do I figure out which line actually causes this?
I cannot simply symbolicate the crash (I assume) since this address is from the heap where the closure was allocated for that specific call. It is different in every occurrence (even with the same device/build).
Is there any possibility to narrow down or even pinpoint the command/line that causes the trap?
