"specialized thunk for @callee_guaranteed"

Using Swift
1

Getting a crash report from production with this message: "specialized thunk for @callee_guaranteed"

Crashed: UserScheduleServiceQueue
0  libswiftFoundation.dylib       0x104b673f8 (Missing)
1  MY_APP01                       0x102feec54 specialized thunk for @callee_guaranteed (@owned ScheduleItem, @owned ScheduleItem) -> (@unowned Bool, @error @owned Error) (UserScheduleService.swift:34)
2  MY_APP01                       0x102ff0e38 specialized _introSortImpl<A>(_:subRange:by:depthLimit:) (UserScheduleService.swift)
3  MY_APP01                       0x102ff142c specialized MutableCollection.sorted(by:) (UserScheduleService.swift)
4  MY_APP01                       0x102ff1c08 partial apply for closure #1 in closure #1 in UserScheduleService.loadPastAndUpcomingVisits(completion:) (UserScheduleService.swift:34)
5  MY_APP01                       0x102feee2c closure #1 in UserScheduleService.loadVisits(direction:completion:) (UserScheduleService.swift:72)

The error seems to happen when sorting a collection (array) of classes by a Date property. The ScheduleItem class is defined in Obj-c.

I'm interested in the actual error message, since I've looked everywhere and cannot find any references online.

Thank you!
Eneko

2

That thunk is just a shim to match the calling convention between what _introSortImpl expects for its closure argument and the normal calling convention for the function that was passed to sort. The real crash is most likely in the inner function.

3

Thank you for clarifying, that makes sense.

In regards of the code block, it's simply this: visits.sorted { $0.startTime < $1.startTime }

Wondering if the startTime property could be nil for some of the elements in the collection. The Obj-C class is defined using NS_ASSUME_NONNULL_BEGIN.

Could that be a bug in Swift? The final error message in the stack says "(Missing)", but no mention of nil-pointer exception.

Thank you,
Eneko

4

I think the best way forward here is to look at this crash report at the assembly level to determine the immediate cause of the crash. That’s not necessarily easy, so before that I think it’s worthwhile to rule out this possibility:

Wondering if the startTime property could be nil for some of the
elements in the collection. The Obj-C class is defined using
NS_ASSUME_NONNULL_BEGIN.

To that end I created a tiny test project with code like this:

let v1 = Visit(startTime: Date(timeIntervalSinceReferenceDate: 0.0))
let v2 = Visit(startTime: Date(timeIntervalSinceReferenceDate: 1.0))
let v3 = Visit(startTime: nil)
let v4 = Visit(startTime: Date(timeIntervalSinceReferenceDate: 2.0))
let visits = [v1, v2, v3, v4]
let visitsSorted = visits.sorted { $0.startTime < $1.startTime }

where Visit is an Objective-C object that claims that startTime is never nil but where it actually can be.

When I run this code (Xcode 9.4, optimised build of Mac command-line tool) I see a crash like this:

(lldb) bt
* … stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0:  … static Foundation.Date._unconditionallyBridgeFromObjectiveC(Swift.Optional<__ObjC.NSDate>) -> Foundation.Date + 54
    frame #1:  … specialized thunk for @callee_guaranteed (@owned Visit, @owned Visit) -> (@unowned Bool, @error @owned Error) [inlined] function signature specialization <Arg[0] = Owned To Guaranteed, Arg[1] = Owned To Guaranteed> of closure #1 ($0=0x0000000100e08450, $1=0x0000000100e08dc0) -> Swift.Bool in xxst.main() -> () at main.swift:18 [opt]
    …
    frame #13: … specialized MutableCollection.sorted(by:) at main.swift:0 [opt]
    frame #14: … main() [inlined] generic specialization <Swift.Array<__ObjC.Visit>> of (extension in Swift):Swift.MutableCollection.sorted(by: (A.Element, A.Element) throws -> Swift.Bool) throws -> Swift.Array<A.Element> at main.swift:0 [opt]
    frame #15: … main() at main.swift:18 [opt]
    frame #16: … main at main.swift:22 [opt]
    …

Note the EXC_BAD_INSTRUCTION, which is a trap indicating that frame 0 (Foundation.Date._unconditionallyBridgeFromObjectiveC…) explicitly caught and trapped in this case.

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

1 Like