Re: [swift-users] Crash with swift_weakLoadStrong in the stack

[Greg Parker via swift-users]

Ah, it's 32-bit iOS. (I assumed i386 or x86_64 from the unaligned instruction 
addresses, but forgot that 32-bit ARM can have those too.) The small-looking 
addresses are okay, then.

That +437720 is still bogus. Ordinarily a symbol with a large offset means that 
the code was actually in some other function, but there was no symbol available 
for that other function. In such cases the symbolicator picks the closest 
symbol available; the large offset means that other symbol was far away. In 
this case that offset is larger than the address itself, which is impossible. 
Something in that frame was calculated incorrectly.

You may get better answers from Crashlytics about this. It looks suspiciously 
like an incorrect backtrace and/or incorrect symbolication of the backtrace.


> On Feb 13, 2017, at 4:25 PM, Jon Shier  wrote:
> 
> 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  App0x665ac 
> Controller.handleSomeNotification(SomeNotification) -> () 
> (Controller.swift:92)
> 1  libswiftCore.dylib 0x131854f swift_unknownWeakLoadStrong + 
> 10
> 2  App0x65cfc 
> Controller.handleFinishSomeNotification(Notification) -> () (Controller.swift)
> 3  App0x65dd8 @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  App0x15b004 specialized 
> specialized NotificationCenter.post (A, forName : NSNotification.Name) -> 
> () (Notifications.swift)
> 10 App0x8d6f4 
> SomeListener.(post(SomeNotification : SomeNotification) -> ()).(closure #1) 
> (SomeNotificationHandler.swift)
> 11 App0x96318 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 App0x4bc38 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 > > wrote:
>> 
>>> 
>>> On Feb 13, 2017, at 12:18 PM, Jon Shier via swift-users 
>>> > 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  App0x665ac 
>>> Controller.handleOtherNotification(Notification) -> () (Controller.swift:92)

Re: [swift-users] Crash with swift_weakLoadStrong in the stack

[Jon Shier via swift-users]

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, 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.dylib0x1b1f5097 
_dispatch_call_block_and_release + 10
13 libdispatch.dylib0x1b1f5083 _dispatch_client_callout + 22
14 libdispatch.dylib0x1b1f95fd 
_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 UIKit0x20c0c82f -[UIApplication 
_run] + 574
21 UIKit0x20c06f61 UIApplicationMain + 
150
22 App  0x4bc38 main (AppDelegate.swift:12)
23 libdispatch.dylib0x1b22250b (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  wrote:
> 
>> 
>> On Feb 13, 2017, at 12:18 PM, Jon Shier via swift-users 
>> > 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  App0x665ac 
>> Controller.handleOtherNotification(Notification) -> () (Controller.swift:92)
>> 1  libswiftCore.dylib 0x131854f swift_unknownWeakLoadStrong + 10
>> 2  App0x65cfc Controller.handleFinish(Notification) 
>> -> () (Controller.swift)
>> 3  App0x65dd8 @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