Crash on launch if Core Telephony is linked — -[CTTelephonyNetworkInfo init]

[skajake]

I added the SDK using Cocoapods. I added the access key to the plist. I added the Settings bundle for metrics opt out.

Upon running the application I get the following stack trace:

[incanus]

What's the exception thrown?

[skajake]

No exception, just a bad access:

[incanus]

Hmm. This functionality should be fine @skajake, so could you email help@mapbox.com since it's probably specific to your token string and we'll go from there?

[1ec5]

What device is this? MGLMapboxEventsData attempts to get the network connection type using Core Telephony, but we’ve had problems with this on some devices in the past: #2687.

[incanus]

Sorry about that @skajake — I may have jumped to a conclusion. Are you using the 3.0.0 version we released to CocoaPods yesterday? It fixes #2687.

[skajake]

This is happening in an Ipad Air 2 simulator. Also happens on a hardware Ipad Air device.

Cocoapods pulled in version 3.0.0 hash:

Mapbox-iOS-SDK: 5e7bafc554a15ebfc615d8b0fa0a0b5d31faac70

[friedbunny]

I was able to replicate this crash with the simulator by manually linking CoreTelephony in a new v3.0.0 CocoaPods project. I'll look in to a fix, but, in the meantime, this can be avoided by not linking CoreTelephony.

Symbolicated backtrace:

* thread #1: tid = 0x14bd61, 0x0000000103a1ffc9 CoreFoundation`CFStringCompare + 25, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x0000000103a1ffc9 CoreFoundation`CFStringCompare + 25
    frame #1: 0x000000010106e329 CoreTelephony`sCTEventForNotificationString(__CFString const*) + 77
    frame #2: 0x00000001010a5a60 CoreTelephony`_CTServerConnectionRegisterForNotification + 22
    frame #3: 0x000000010108df8b CoreTelephony`-[CTTelephonyNetworkInfo setUpServerConnection] + 215
    frame #4: 0x000000010108e230 CoreTelephony`-[CTTelephonyNetworkInfo init] + 257
  * frame #5: 0x0000000100dd2dac Mapbox`-[MGLMapboxEventsData init](self=<unavailable>, _cmd=<unavailable>) + 588 at MGLMapboxEvents.m:82 [opt]
    frame #6: 0x0000000100dd4c10 Mapbox`-[MGLMapboxEvents resumeMetricsCollection](self=<unavailable>, _cmd="H\x89\U00000088\x8b\x05Y\xbe") + 416 at MGLMapboxEvents.m:413 [opt]
    frame #7: 0x0000000100dd3ad0 Mapbox`-[MGLMapboxEvents init](self=<unavailable>, _cmd="\x90`\326�\x01") + 2064 at MGLMapboxEvents.m:252 [opt]
    frame #8: 0x0000000100dd4266 Mapbox`__32+[MGLMapboxEvents sharedManager]_block_invoke_2(.block_descriptor=<unavailable>) + 38 at MGLMapboxEvents.m:316 [opt]
    frame #9: 0x000000010430149b libdispatch.dylib`_dispatch_client_callout + 8
    frame #10: 0x00000001042ece28 libdispatch.dylib`dispatch_once_f + 543
    frame #11: 0x0000000100dd422f Mapbox`__32+[MGLMapboxEvents sharedManager]_block_invoke [inlined] _dispatch_once(block=<unavailable>) + 16 at once.h:68 [opt]
    frame #12: 0x0000000100dd421f Mapbox`__32+[MGLMapboxEvents sharedManager]_block_invoke(.block_descriptor=<unavailable>) + 79 at MGLMapboxEvents.m:315 [opt]
    frame #13: 0x0000000100dd414d Mapbox`+[MGLMapboxEvents sharedManager](self=<unavailable>, _cmd=<unavailable>) + 221 at MGLMapboxEvents.m:325 [opt]
    frame #14: 0x0000000100df0aac Mapbox`+[MGLAccountManager setAccessToken:](self=<unavailable>, _cmd=<unavailable>, accessToken=<unavailable>) + 204 at MGLAccountManager.m:74 [opt]
    frame #15: 0x0000000100df06ae Mapbox`+[MGLAccountManager load](self=<unavailable>, _cmd=<unavailable>) + 222 at MGLAccountManager.m:31 [opt]
    frame #16: 0x00000001015bcdff libobjc.A.dylib`call_load_methods + 731
    frame #17: 0x00000001015bd892 libobjc.A.dylib`load_images + 123
    frame #18: 0x0000000100c2aa75
    frame #19: 0x0000000100c357a6
    frame #20: 0x0000000100c3574b
    frame #21: 0x0000000100c34aca
    frame #22: 0x0000000100c34b5f
    frame #23: 0x0000000100c2ad79
    frame #24: 0x0000000100c2dfed
    frame #25: 0x0000000100c2a251
    frame #26: 0x00007fff6d8b2656 dyld`dyld::useSimulatorDyld(int, macho_header const*, char const*, int, char const**, char const**, char const**, unsigned long*) + 1702
    frame #27: 0x00007fff6d8b105c dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 208
    frame #28: 0x00007fff6d8ad276 dyld`dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 512
    frame #29: 0x00007fff6d8ad036 dyld`_dyld_start + 54

[davidbroza]

Not linking CoreTelephony does not seems to work for me. Issue is still present.

[skajake]

As best as I can tell, I am not linking CoreTelephony, but I am investigating further. Crash still occuring.

[skajake]

So I was able to get the project to run by removing a specific pod dependency from my project. Namely: https://github.com/vfr/Reader

Its podspec pulls in the following frameworks: "UIKit", "Foundation", "CoreGraphics", "QuartzCore", "ImageIO", "MessageUI"

[friedbunny]

@skajake Interesting, looks like MessageUI probably pulls in CoreTelephony.

[skajake]

i stripped out MessageUI from Reader and it is now working. So that was the culprit.

[friedbunny]

Packaged builds of v3.0.0 crash on all devices when CoreTelephony is linked. ios-app does not crash on phones or simulators with CoreTelephony, however — this makes me believe it has to do with our packaging process.

[1ec5]

iosapp doesn’t link CoreTelephony as far as I can tell.

[friedbunny]

iosapp doesn't (and shouldn't) link CoreTelephony, but manually linking it does not crash and works as expected.

[skajake]

Update: I am still getting the crash, but only when running on physical hardware (iPad Air 2). Only seems to happen when pulling in https://github.com/yapstudios/YapDatabase via Cocoapods. Can't seem to figure out what in YapDatabase is linking in telephony.