These crashes are uploaded from device, namely an iPad 4 (running the app in compatibility mode) uploaded through Crashlytics and then downloaded from there. I haven’t been able to reproduce the crash and so I haven’t seen a raw dump. Here’s the full crash stack, redacted, from an iPad 4 running iOS 10.1.1 (this is an iOS 10+ app).
#0. Crashed: com.apple.main-thread 0 App 0x665ac Controller.handleSomeNotification(SomeNotification) -> () (Controller.swift:92) 1 libswiftCore.dylib 0x131854f swift_unknownWeakLoadStrong + 10 2 App 0x65cfc Controller.handleFinishSomeNotification(Notification) -> () (Controller.swift) 3 App 0x65dd8 @objc Controller.handleSomeOtherNotification(Notification) -> () + 437720 4 CoreFoundation 0x1bafa761 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 10 5 CoreFoundation 0x1bafa09d _CFXRegistrationPost + 386 6 CoreFoundation 0x1baf9e81 ___CFXNotificationPost_block_invoke + 40 7 CoreFoundation 0x1bb5581d -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1188 8 CoreFoundation 0x1ba5a09d _CFXNotificationPost + 540 9 App 0x15b004 specialized specialized NotificationCenter.post<A> (A, forName : NSNotification.Name) -> () (Notifications.swift) 10 App 0x8d6f4 SomeListener.(post(SomeNotification : SomeNotification) -> ()).(closure #1) (SomeNotificationHandler.swift) 11 App 0x96318 partial apply for SomeListener.(post(SomeNotification : SomeNotification) -> ()).(closure #1) (SomeNotificationHandler.swift) 12 libdispatch.dylib 0x1b1f5097 _dispatch_call_block_and_release + 10 13 libdispatch.dylib 0x1b1f5083 _dispatch_client_callout + 22 14 libdispatch.dylib 0x1b1f95fd _dispatch_main_queue_callback_4CF + 890 15 CoreFoundation 0x1bb0aa17 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8 16 CoreFoundation 0x1bb08cff __CFRunLoopRun + 1422 17 CoreFoundation 0x1ba58073 CFRunLoopRunSpecific + 486 18 CoreFoundation 0x1ba57e81 CFRunLoopRunInMode + 104 19 GraphicsServices 0x1d204bfd GSEventRunModal + 156 20 UIKit 0x20c0c82f -[UIApplication _run] + 574 21 UIKit 0x20c06f61 UIApplicationMain + 150 22 App 0x4bc38 main (AppDelegate.swift:12) 23 libdispatch.dylib 0x1b22250b (Missing) Essentially I have a listener waiting on a background queue for a push notification to come in, which then repackages the payload into a Notification using a generic convenience method I wrote, and posted onto the main queue. Controller is listening for this two separate notifications, one of which is the SomeNotification. But the @objc method in there is the selector for the other notification, SomeOther. There should be no path between 3 and 2 in the stack, and there are no weak references I can see, except perhaps the implicit ones from NotificationCenter. Badly resymbolicated log? Is that even possible? Jon > On Feb 13, 2017, at 6:52 PM, Greg Parker <gpar...@apple.com> wrote: > >> >> On Feb 13, 2017, at 12:18 PM, Jon Shier via swift-users >> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: >> >> Swift Users: >> I’m currently seeing a crash in my iOS app that has no apparent cause, >> but a bit of Swift runtime machinery in the stack has me confused. >> >> #0. Crashed: com.apple.main-thread >> 0 App 0x665ac >> Controller.handleOtherNotification(Notification) -> () (Controller.swift:92) >> 1 libswiftCore.dylib 0x131854f swift_unknownWeakLoadStrong + 10 >> 2 App 0x65cfc Controller.handleFinish(Notification) >> -> () (Controller.swift) >> 3 App 0x65dd8 @objc >> Controller.handleNotification(Notification) -> () + 437720 >> >> Controller.swift: 92 is a call to a custom UIView subclass method that takes >> an optional date contained extracted from the notification. Any idea what >> the core callout would be due to? There are no weak or unknown values being >> used here. Once the notification observers are called it’s all internal to >> Controller. >> >> One thing I just noticed is that the line at 3 is the selector for a >> different notification, which should lead down the path see from 2 onward. >> It’s redacted and so not easy to see, but in Controller, there’s no path >> that leads from handleNotification to handleFinish. > > That backtrace does look strange. Even if there were some surprising call to > swift_unknownWeakLoadStrong() in handleFinish(), there's no way that > swift_unknownWeakLoadStrong() would call handleOtherNotification(). > > (swift_unknownWeakLoadStrong + 10 is the instruction after a call, assuming > you're on 64-bit iOS simulator, but that call is to > swift::isNativeSwiftWeakReference() which itself doesn't call anything.) > > Also, in frame 3, the byte offset from the start of handleNotification() is > larger than the address itself. And all of these addresses look too small if > you're on 64-bit. > > Where did this backtrace come from? Do you have a crash log as generated by > the OS? > > > -- > Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime > Wrangler
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
