Firebase-ios-sdk: GAD_GADNetwork_arm64_7_67_0 crash

[KorolZhu]

Step 0: Are you in the right place?

• For issues or feature requests related to __the code in this repository__
  file a Github issue.
  
  
  
  • If this is a __feature request__ please use the Feature Request template.
  
  
• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general (non-iOS) Firebase discussion, use the firebase-talk
  google group.
• For backend issues, console issues, and other non-SDK help that does not fall under one
  of the above categories, reach out to
  Firebase Support.
• Once you've read this section and determined that your issue is appropriate for
  this repository, please delete this section.

[REQUIRED] Step 1: Describe your environment

• Xcode version: 12.3
• Firebase SDK version: - Firebase/AdMob (6.34.0). - Google-Mobile-Ads-SDK (7.67.0)
• Installation method: CocoaPods
• Firebase Component: Core, AdMob, Crashlytics

[REQUIRED] Step 2: Describe the problem

many crash in GAD_GADNetwork_arm64_7_67_0

Steps to reproduce:

can not reproduce, most call stack like this:

Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x19fe700f8 objc_msgSend + 24
1 CoreFoundation 0x18ade6388 -[__NSDictionaryM objectForKeyedSubscript:] + 184
2 CoreTelephony 0x18b463024 -[CTTelephonyNetworkInfo currentRadioAccessTechnology] + 188
3 HelloTalk_Binary 0x101d954a8 GAD_GADNetwork_arm64_7_67_0 + 4322022568
4 HelloTalk_Binary 0x101d952f0 GAD_GADNetwork_arm64_7_67_0 + 4322022128
5 Foundation 0x18c254850 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 24
6 Foundation 0x18c141740 -[NSBlockOperation main] + 104
7 Foundation 0x18c256ca4 __NSOPERATION_IS_INVOKING_MAIN__ + 24
8 Foundation 0x18c1413c8 -[NSOperation start] + 808
9 Foundation 0x18c25774c __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 24
10 Foundation 0x18c2571d4 __NSOQSchedule_f + 184
11 libdispatch.dylib 0x18ab07fb8 _dispatch_block_async_invoke2 + 148
12 libdispatch.dylib 0x18aaf9db0 _dispatch_client_callout + 20
13 libdispatch.dylib 0x18ab077ac _dispatch_main_queue_callback_4CF + 836
14 CoreFoundation 0x18ae8111c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
15 CoreFoundation 0x18ae7b120 __CFRunLoopRun + 2508
16 CoreFoundation 0x18ae7a21c CFRunLoopRunSpecific + 600
17 GraphicsServices 0x1a297e784 GSEventRunModal + 164
18 UIKitCore 0x18d8b8fe0 -[UIApplication _run] + 1072
19 UIKitCore 0x18d8be854 UIApplicationMain + 168
20 HelloTalk_Binary 0x1025f0440 main + 18 (main.m:18)
21 libdyld.dylib 0x18ab3a6b0 start + 4

[morganchen12]

This call

-[CTTelephonyNetworkInfo currentRadioAccessTechnology]

is a system call with no dependencies on your app that should never crash, and since it's crashing in objc_msgSend, it's likely the crash is caused by memory corruption elsewhere. Try some of the strategies in Apple's documentation to see if you can identify any memory issues:

• Investigating Memory Access Crashes
• Investigating Crashes for Zombie Objects

[KorolZhu]

@morganchen12 can not reproduce

yes, It's caused by this call method
[CTTelephonyNetworkInfo currentRadioAccessTechnology]

and Here's a solution:

This bug occurs when CTTelephonyNetworkInfo get notifications after it is released. Instead you should use:

static CTTelephonyNetworkInfo *netInfo; static dispatch_once_t dispatchToken; if (!netInfo) { dispatch_once(&dispatchToken, ^{ netInfo = [[CTTelephonyNetworkInfo alloc] init]; }); }
because, as others said: "There is an iOS bug that causes instances of the CTTelephonyNetworkInfo class to sometimes get notifications after they have been deallocated. Instead of instantiating, using, and releasing instances you must instead retain and never release them to work around the bug." More information here

https://stackoverflow.com/questions/33748737/coretelephony-crash-non-reproducible

can you try to use this solution to fix this. or Can I control not calling methods of this class CTTelephonyNetworkInfo

[paulb777]

That stackoverflow post is from 2015. What iOS version(s) see the crash?

[KorolZhu]

However, this problem has not been solved. It seems to be a bug in the system. The version number is as follows

Here is the same problem, can you refer to his solution

https://github.com/mixpanel/mixpanel-swift/issues/367

[paulb777]

@KorolZhu Thanks for sharing the analysis. I created the internal issue b/178475238 to track.

[UIowaEABurns]

Hello,

GMA SDK already creates a single instance of CTTelephonyNetworkInfo and retains it for the lifetime of the application. So, it cannot be deallocated during notification handling.

When did this issue start, or did it start at any particular time? GMA SDK logic regarding CTTelephonyNetworkInfo has not changed recently.

As @morganchen12 mentioned, this is a system call that should not crash, and I agree it seems like this could be caused by memory corruption or thread safety issues.

[KorolZhu]

This crash started with Google-Mobile-Ads-SDK 7.67. Before that, version 7.64 was used. There was no such problem in version 7.64

[KorolZhu]

@paulb777 @morganchen12 @UIowaEABurns

Hi, all

I found a post be exactly alike to me in Google forum. They also said that the problem was started from the 7.67 version. The screenshot above also confirmed this point. In my app, this crash is now ranked first, and there are about 3000 crash in a month. This is a serious problem. thanks.

https://groups.google.com/forum/embed/#!topic/google-admob-ads-sdk/b1ezfq9yNno
https://groups.google.com/g/google-admob-ads-sdk/c/6eARwe3JTAk/m/ew76T5b0BwAJ?pli=1

[alflix]

We have this problem since Google-Mobile-Ads-SDK 7.67 too. the crash rate is about 0.2%, most of crash is happen in iOS12+

Stack Trace:

0 libobjc.A.dylib objc_msgSend + 16
1 CoreFoundation -[__NSDictionaryM objectForKeyedSubscript:] + 216
2 CoreTelephony 0x00000001d9713000 + 326660
3 Boomplay -[GADNetwork updateRadioAccessTechnology] (GADNetwork.m:216)
4 Boomplay __49-[GADNetwork enableRadioAccessTechnologyChecking]_block_invoke (GADNetwork.m:185)
5 Foundation ___NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
6 Foundation -[NSBlockOperation main] + 72
7 Foundation -[__NSOperationInternal _start:] + 740
8 Foundation ___NSOQSchedule_f + 272
9 libdispatch.dylib __dispatch_block_async_invoke2 + 104
10 libdispatch.dylib __dispatch_client_callout + 16
11 libdispatch.dylib __dispatch_main_queue_callback_4CF$VARIANT$mp + 1068
12 CoreFoundation ___CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
13 CoreFoundation ___CFRunLoopRun + 1924
14 CoreFoundation CFRunLoopRunSpecific + 436
15 GraphicsServices GSEventRunModal + 104
16 UIKitCore UIApplicationMain + 212
17 Boomplay main (main.m:13)
18 libdyld.dylib _start + 4

0 Thread

[UIowaEABurns]

Hello,

Thank you for the updates-- my best guess is that these crashes are occurring due to race conditions inside of CTTelephonyNetworkInfo. I'm going to disable some of the accesses being made by the SDK, which should make the SDK behave like pre-7.67.0 releases. These changes are scheduled for a release in the week of Feb 8.

[alflix]

Hello, the new version of Google-Mobile-Ads-SDK had been released, is this issue has been fixed?

https://developers.google.com/admob/ios/rel-notes

[UIowaEABurns]

Not yet unfortunately-- that release was cut a couple weeks ago, so this fix did not make it. Our next release will have the update.