Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iOS 5 only crashes #32

Closed
soleares opened this issue Feb 19, 2013 · 8 comments
Closed

iOS 5 only crashes #32

soleares opened this issue Feb 19, 2013 · 8 comments

Comments

@soleares
Copy link

My users are sometimes getting iOS 5 only crashes. I started seeing these after switching from Apple's Reachability 2.2 to this library so I think it may be related to the GCD additions which I'm not using.

Here's how I use it:

  • Call startNotifier in applicationDidBecomeActive:
  • Call stopNotifier in applicationWillResignActive:
  • Use the notification only and do not check the status directly.

The crash occurs soon after the app becomes active, but it don't think the watchdog killed it (no "ate bad food" 0x8badf00d). It looks like the crash is in the SCNetworkReachability XPC service.

I'm not able to reproduce it myself after a lot of testing (bad network, memory warnings, etc) so I'm hoping that someone has further insight. Here's the relevant part of the crash log:

OS Version: iPhone OS 5.1.1 (9B206)
Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000008
Crashed Thread: 7

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x35b32054 semaphore_wait_trap + 8
1 libdispatch.dylib 0x33e66158 _dispatch_semaphore_wait_slow + 184
2 libdispatch.dylib 0x33e66188 dispatch_semaphore_wait$VARIANT$up + 28
3 libxpc.dylib 0x3227889a xpc_connection_send_message_with_reply_sync + 206
4 SystemConfiguration 0x339d4be6 _reach_server_target_status + 938
5 SystemConfiguration 0x339d5d56 __SCNetworkReachabilityServer_targetStatus + 14
6 SystemConfiguration 0x339beaee __SCNetworkReachabilityGetFlags + 198
7 SystemConfiguration 0x339bf9ca __SCNetworkReachabilityScheduleWithRunLoop + 826
8 SystemConfiguration 0x339bfe38 SCNetworkReachabilitySetDispatchQueue + 80
9 mrl 0x0005f2e8 -Reachability startNotifier
10 mrl 0x0004247a -AppDelegate startReachability
11 mrl 0x0003f03c -AppDelegate applicationDidBecomeActive:
12 UIKit 0x33210c2a -[UIApplication _stopDeactivatingForReason:] + 182
13 UIKit 0x332a84f2 -[UIApplication _handleApplicationResumeEvent:] + 1510
14 UIKit 0x331ccafc -[UIApplication handleEvent:withNewEvent:] + 1068
15 UIKit 0x331cc560 -[UIApplication sendEvent:] + 48
16 UIKit 0x331cbf34 _UIApplicationHandleEvent + 5820
17 GraphicsServices 0x337be224 PurpleEventCallback + 876
18 CoreFoundation 0x35aa051c CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION + 32
19 CoreFoundation 0x35aa04be __CFRunLoopDoSource1 + 134
20 CoreFoundation 0x35a9f30c __CFRunLoopRun + 1364
21 CoreFoundation 0x35a2249e CFRunLoopRunSpecific + 294
22 CoreFoundation 0x35a22366 CFRunLoopRunInMode + 98
23 GraphicsServices 0x337bd432 GSEventRunModal + 130
24 UIKit 0x331facce UIApplicationMain + 1074
25 mrl 0x0003e79e main (main.m:16)
26 mrl 0x0003e738 start + 32

Thread 7 name: Dispatch queue: com.apple.SystemConfiguration.SCNetworkReachability.xpcq
Thread 7 Crashed:
0 libdispatch.dylib 0x33e669e8 _dispatch_retain$VARIANT$up + 0
1 libdispatch.dylib 0x33e644f8 dispatch_group_async_f$VARIANT$up + 16
2 SystemConfiguration 0x339be7e2 __SCNetworkReachabilityPerform + 126
3 SystemConfiguration 0x339d5128 ___reach_connection_create_block_invoke_1 + 320
4 libxpc.dylib 0x3227d8c2 XPC_CONNECTION_EVENT_HANDLER_CALLOUT + 30
5 libxpc.dylib 0x32276d5c _xpc_connection_recv_message + 500
6 libxpc.dylib 0x32276b18 _xpc_connection_wakeup_recv + 160
7 libxpc.dylib 0x322769b8 _xpc_connection_wakeup2 + 1264
8 libxpc.dylib 0x322763f6 _xpc_connection_wakeup + 62
9 libdispatch.dylib 0x33e67252 _dispatch_source_invoke + 510
10 libdispatch.dylib 0x33e64b1e _dispatch_queue_invoke$VARIANT$up + 42
11 libdispatch.dylib 0x33e64c3e _dispatch_queue_drain + 166
12 libdispatch.dylib 0x33e64b12 _dispatch_queue_invoke$VARIANT$up + 30
13 libdispatch.dylib 0x33e64c3e _dispatch_queue_drain + 166
14 libdispatch.dylib 0x33e64b12 _dispatch_queue_invoke$VARIANT$up + 30
15 libdispatch.dylib 0x33e65784 _dispatch_worker_thread2 + 208
16 libsystem_c.dylib 0x34ce5df4 _pthread_wqthread + 288
17 libsystem_c.dylib 0x34ce5cc8 start_wqthread + 0

@tonymillion
Copy link
Owner

I'll look into this, but one note, you dont need to stop/start the notifier when you go to the background, it'll work fine if you just start it at app startup and leave it running. (which is what I do).

I dont actually have an iOS5 device but I have a couple of theories I'll test.

@soleares
Copy link
Author

I start and stop the notifier based on either specific advice from a WWDC session or just the general recommendation to turn off unnecessary things when the app isn't active or foreground - I don't remember which. I assume that it has an impact on battery life as well, but I'm not sure if in reality it does. If there's no effect, I can change that code although there may be other possible issues such as: https://github.com/AFNetworking/AFNetworking/issues/512.

I think the difference is that you schedule the notifications with a queue (SCNetworkReachabilitySetDispatchQueue) and the other Reachability code I've used in the past (Apple Reachability and AFNetworking) schedules them on a runloop (SCNetworkReachabilityScheduleWithRunLoop). Maybe there's an iOS 5 specific issue with SCNetworkReachabilitySetDispatchQueue although I haven't been able to find anyone else reporting it online.

I'm not able to replicate yet, although I do get a few crash reports for this everyday from my iOS 5 users. I've tried testing with an iPad 1 (5.1.1) using the Network Link Conditioner (though an iPhone hotspot) and mixed in some memory warnings as well without luck.

If you have some ideas or theories, let me know. Thanks for your time!

@tonymillion
Copy link
Owner

Yeah there is no need (and no effect on battery life) to stop the reachability notifier when moving to background, it was originally build for a VoIP app so it was designed to just stay running all the time (iOS is very clever about background processing)

Reachability was originally designed for iOS5 so unless a new change has broken backwards compatibility it should work fine. If I can find an iOS5 device among my test units I will definitely test it.

@cerupcat
Copy link

Ever find out why this crash occurred? We're having the same issue.

@soleares
Copy link
Author

It's an issue with the dispatch queue setup. It happens even if you don't use the queue based reachability methods and only affects iOS 5.

I switched to the following Reachability code and haven't had an crashes since:
https://gist.github.com/darkseed/1182373

@cerupcat
Copy link

Thank @soleares, I'll check it out. We're using iOS5 specifically for a project.

@twumdjin
Copy link

twumdjin commented May 8, 2014

Running into this issue too. This appears to be caused by this reachability library posting notifications on the main thread. If the observers for that notification check reachability status they will invariably be calling SCNetworkReachabilityGetFlags, which according to Apple's Docs should not be called on the main thread because it might require a DNS lookup and could take over 30 seconds and so trigger iOS Application Watchdog, that will kill the app for hanging.

Here's the reference: https://developer.apple.com/Library/ios/samplecode/Reachability/Listings/ReadMe_txt.html

Fix would be to ensure that the observer methods use GCD to react to reachability status on a separate thread.

@tonymillion
Copy link
Owner

I'm closing this as I definitely don't support iOS5 any more

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants