Crash -[GADNetwork updateRadioAccessTechnology] + 216

[Marco Fontana]

Hello, since the new update of iOS GAD SDK (version  7.67.0). I received a crash on this line:

-[GADNetwork updateRadioAccessTechnology] + 216

Users reported that this crash happens usually when they are in the background and connected to the internet. If they are not connected to the internet this does not happen.

If they able wifi after they are in the background the app usually crashes after 20-30 seconds for those users.

What should I do?

Thank you,

Marco

[Mobile Ads SDK Forum Advisor Prod]

Hi Marco,

Thank you for bringing this background crash on version 7.67.0 of our SDK when connected to the internet up to our attention. For us to investigate this could you try to reliably reproduce this crash? If you can, could you try to reproduce this in a minimally modified sample app? If you have a way of reliably reproducing the crash, could you tell us the steps to reproduce it?

Regards,

Aryeh Baker Mobile Ads SDK Team

ref:_00D1U1174p._5004Q276ixW:ref

[Early Studio Team]

Hello Aryeh,

unfortunately we are not able to reproduce the problem since it is a bug which happens to some users.

From what we see it also does not depened on iOS version or phone model.

What users are reporting is that if they stay disconnected from internet it does not happen and if they activate internet after 20/30 seconds the app started crashing, they also said that this happens only why app is in background.

We have only does logs, from our side we can say that this happen after we upgraded to latest version of Google Ads SDK.

Thank you.

[Mobile Ads SDK Forum Advisor Prod]

Hi Marco,

Thank you for getting back. In order for us to look into this we will need a way to reliably reproduce the issue.

[Marco Fontana]

Dear Aryeh,

unfortunately we cannot reproduce it on our own test machines but there is a big number of crashes due to this problem.

We can give you access to our Crashalytics dashboard if you want to check, we have a big production app and we are very concerned about this issue.

[Mobile Ads SDK Forum Advisor Prod]

Hi Marco,

We would like stack traces and you can send them privately to author. We most probably would need reproduction steps of the issue though.

[Marco Fontana]

Hello, 

this is the stack trace:

Crashed: com.apple.main-thread

0  libobjc.A.dylib                0x1a5a155d4 objc_msgSend + 20

1  CoreFoundation                 0x192069234 -[__NSDictionaryM objectForKeyedSubscript:] + 180

2  CoreTelephony                  0x1926b7314 -[CTTelephonyNetworkInfo currentRadioAccessTechnology] + 184

3  eSound                         0x1010418c8 -[GADNetwork updateRadioAccessTechnology] + 216 (GADNetwork.m:216)

4  eSound                         0x101041710 __49-[GADNetwork enableRadioAccessTechnologyChecking]_block_invoke + 185 (GADNetwork.m:185)

5  Foundation                     0x19341dcc8 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16

6  Foundation                     0x19331ab18 -[NSBlockOperation main] + 100

7  Foundation                     0x19341ff80 __NSOPERATION_IS_INVOKING_MAIN__ + 20

8  Foundation                     0x19331a7d4 -[NSOperation start] + 784

9  Foundation                     0x193420978 __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 20

10 Foundation                     0x193420444 __NSOQSchedule_f + 180

11 libdispatch.dylib              0x191d98cb8 _dispatch_block_async_invoke2 + 104

12 libdispatch.dylib              0x191db6280 _dispatch_client_callout + 16

13 libdispatch.dylib              0x191d985b8 _dispatch_main_queue_callback_4CF$VARIANT$armv81 + 856

14 CoreFoundation                 0x1920fcc30 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12

15 CoreFoundation                 0x1920f70e8 __CFRunLoopRun + 2480

16 CoreFoundation                 0x1920f6200 CFRunLoopRunSpecific + 572

17 GraphicsServices               0x1a8273598 GSEventRunModal + 160

18 UIKitCore                      0x1949bfbcc -[UIApplication _run] + 1052

19 UIKitCore                      0x1949c51a0 UIApplicationMain + 164

20 eSound                         0x100c32004 main + 14 (main.m:14)

21 libdyld.dylib                  0x191dd5588 start + 4

Maybe you can also explain what this method enableRadioAccessTechnologyChecking and updateRadioAccessTechnology do and why it may crash at this point.

[Mobile Ads SDK Forum Advisor Prod]

Hi Marco,

I work along with Aryeh and thank you for sharing this information. However, it is really important for us to reproduce this issue first hand so we can pinpoint what causes the crash error. That being said, would it be possible for you to provide us with a sample project file (preferably based on our sample apps) wherein this behavior is occurring? If yes, kindly send the project file to our email alias below so we can continue our investigation.

mobileads...@gmail.com


Regards,

Sherwin Diesta Mobile Ads SDK Team

ref:_00D1U1174p._5004Q276ixW:ref

[AndyW]

Just wanted to add that we are also seeing this crash since updating to 7.67. Although this is easily our largest crash, it still represents a tiny proportion of sessions and our QA has never seen it, I think that hoping to repro may be unrealistic. Here are some callstacks as they seem slightly different to Marco's:

Crashed: com.apple.main-thread
0  libsystem_platform.dylib       0x1c8f9d15c os_unfair_lock_lock + 16
1  CoreFoundation                 0x1c93bc8d4 _cow_copy + 56
2  CoreFoundation                 0x1c928dd6c -[__NSDictionaryM copyWithZone:] + 204
3  MyProj                            0x100f1ab44 -[GADNetwork setServiceRadioAccessTechnology:] + 265 (GADNetwork.m:265)
4  MyProj                            0x100f1a978 -[GADNetwork updateRadioAccessTechnology] + 222 (GADNetwork.m:222)
5  MyProj                            0x100f1a750 __49-[GADNetwork enableRadioAccessTechnologyChecking]_block_invoke + 185 (GADNetwork.m:185)
6  Foundation                     0x1c9e136b8 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 24
7  Foundation                     0x1c9d190d8 -[NSBlockOperation main] + 76
8  Foundation                     0x1c9d18568 -[__NSOperationInternal _start:] + 748
9  Foundation                     0x1c9e15474 __NSOQSchedule_f + 276
10 libdispatch.dylib              0x1c8db6004 _dispatch_block_async_invoke2 + 144

Crashed: com.apple.main-thread
0  libsystem_platform.dylib       0x1f71e9d30 os_unfair_lock_lock$VARIANT$armv81 + 16
1  CoreFoundation                 0x1b13d9c5c _cow_copy + 52
2  CoreFoundation                 0x1b14eada0 -[__NSDictionaryM copy] + 160
3  MyProj                            0x1008c2b44 -[GADNetwork setServiceRadioAccessTechnology:] + 265 (GADNetwork.m:265)
4  MyProj                            0x1008c2978 -[GADNetwork updateRadioAccessTechnology] + 222 (GADNetwork.m:222)
5  MyProj                            0x1008c2750 __49-[GADNetwork enableRadioAccessTechnologyChecking]_block_invoke + 185 (GADNetwork.m:185)
6  Foundation                     0x1b272dcc8 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16

...

Crashed: com.apple.main-thread
0  libobjc.A.dylib                0x211c6b530 objc_msgSend + 16
1  CoreFoundation                 0x212969b3c -[__NSDictionaryM objectForKeyedSubscript:] + 216
2  CoreTelephony                  0x215852c04 -[CTTelephonyNetworkInfo currentRadioAccessTechnology] + 192
3  MyProj                            0x101782908 -[GADNetwork updateRadioAccessTechnology] + 216 (GADNetwork.m:216)
4  MyProj                            0x101782750 __49-[GADNetwork enableRadioAccessTechnologyChecking]_block_invoke + 185 (GADNetwork.m:185)
5  Foundation                     0x2134e0cf4 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
6  Foundation                     0x2133ecd90 -[NSBlockOperation main] + 72
7  Foundation                     0x2133ec278 -[__NSOperationInternal _start:] + 740
8  Foundation                     0x2134e2a78 __NSOQSchedule_f + 272

Please could you comment on whether the issue might have been addressed in 7.68.0? (release notes suggest not)

Please could you comment on whether there's likely to be any workaround (e.g. an option that lets users opt out of radio access technology checking).

Thanks,

Andy.

[AndyW]

Is it possible that this is relevant: https://stackoverflow.com/questions/14238586/coretelephony-crash

From someone who worked on Testflight:

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.

Alternatively there's this from OpenRadar: https://openradar.appspot.com/46873673

So it would appear that it's not safe to read serviceCurrentRadioAccessTechnology on CTServiceRadioAccessTechnologyDidChange's callback thread.

Thanks,

Andy.

[Marco Fontana]

Hello,

I want to add another callstack too:

Crashed: com.apple.main-thread

0  libsystem_platform.dylib       0x1e642c00c os_unfair_lock_lock + 16

1  CoreFoundation                 0x19e48a88c _cow_copy + 56

2  CoreFoundation                 0x19e5a4580 -[__NSDictionaryM copy] + 156

3  eSound                         0x102ca8198 -[GADNetwork setServiceRadioAccessTechnology:] + 265 (GADNetwork.m:265)

4  eSound                         0x102ca7fcc -[GADNetwork updateRadioAccessTechnology] + 222 (GADNetwork.m:222)

5  eSound                         0x102ca7da4 __49-[GADNetwork enableRadioAccessTechnologyChecking]_block_invoke + 185 (GADNetwork.m:185)

6  Foundation                     0x19f85e7f4 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 24

7  Foundation                     0x19f751120 -[NSBlockOperation main] + 104

8  Foundation                     0x19f860bb8 __NSOPERATION_IS_INVOKING_MAIN__ + 24

9  Foundation                     0x19f750da8 -[NSOperation start] + 808

10 Foundation                     0x19f861624 __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 24

11 Foundation                     0x19f8610d0 __NSOQSchedule_f + 184

12 libdispatch.dylib              0x19e14e834 _dispatch_block_async_invoke2 + 148

13 libdispatch.dylib              0x19e140ac8 _dispatch_client_callout + 20

14 libdispatch.dylib              0x19e14e04c _dispatch_main_queue_callback_4CF + 836

15 CoreFoundation                 0x19e4bf1e4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16

16 CoreFoundation                 0x19e4b93b4 __CFRunLoopRun + 2508

17 CoreFoundation                 0x19e4b84bc CFRunLoopRunSpecific + 600

18 GraphicsServices               0x1b4fca820 GSEventRunModal + 164

19 UIKitCore                      0x1a0e65164 -[UIApplication _run] + 1072

20 UIKitCore                      0x1a0e6a840 UIApplicationMain + 168

21 eSound                         0x1028ea1a0 main + 14 (main.m:14)

22 libdyld.dylib                  0x19e17fe40 start + 4

Now it seems that the crashes are two in GADNetwrok.m:

1. -[GADNetwork setServiceRadioAccessTechnology:] + 265

2. -[GADNetwork updateRadioAccessTechnology] + 216

Reproducing a demo with the crash is nearly impossible, we are considering upgrading to 7.68.0 but we don't think this issue will be solved with that version.

Should we downgrade?

Talking with a Google Engineer he said that it seems a problem when using and setting cellular GSM connections like 2G, 3G & 4G, he's trying to create a reproducible demo but it is hard to do it.

[Mobile Ads SDK Forum Advisor Prod]

Hi Marco and Andy,

Thank you for the extra info. I shared your stacktraces and comments with the rest of my team. If we have actionable information or questions we will get back to you. Since stacktrace detected bugs are notorious to pin down we ask to find a way to replicate.

Regards,

Aryeh Baker Mobile Ads SDK Team

ref:_00D1U1174p._5004Q276ixW:ref

[Marco Fontana]

Hello, any news about this?

I talked with my account manager and he says that this bug has been recognized by the Mobile Ads SDK Team and a fix will be published soon.

Any informations about this?

Thank you,

Marco

[Mobile Ads SDK Forum Advisor Prod]

Hi Marco,

Thank you for your message. I’m afraid we do not have an update yet, but let me follow up this with the team. We will let you know as soon as we receive feedback.

Regards,

Sherwin Diesta Mobile Ads SDK Team

ref:_00D1U1174p._5004Q276ixW:ref

[Marco Fontana]

Thank you Sherwin!

We are receiving lots of complaints about this issue.

Just to know, can you confirm that this bug has been taken under investigation by Google as my account manager said?

Thank you,

Maro

[Mobile Ads SDK Forum Advisor Prod]

Hi Marco,

Thank you for responding back. I work along with Aryeh and Sherwin. As such I will be assisting you today on this issue. Having looked over the post and checked with my team. I can say that it is currently being looking into and once we have more information we will definitely pass it along to you.

Regards,

William Pescherine Mobile Ads SDK Team

ref:_00D1U1174p._5004Q276ixW:ref

[Marco Fontana]

Hi William,

thank you so much!

We hope to have information soon because we do not know how to handle the complaints of all the users that are experiencing this problem since we do not have control over this SDK.

Thank you for your time and I hope to hear back from you soon!

Best regards,

Marco

[Marco Fontana]

Hello, any news about this? I have seen you released a new update has the crash been fixed with that update?

[Mobile Ads SDK Forum Advisor Prod]

Hi Marco,

Thank you for checking back with us. I looked at this again and see that it is still being looked at with no feedback to give as of this moment. Once we see something we will be certain to pass it along or it will be posted in the release notes .

[riverboat...@gmail.com]

Apparently "still be checked into"? 6 months later...

Crashed: com.apple.main-thread

0  libobjc.A.dylib                0x1ac9f20e8 objc_msgSend + 8

1  CoreFoundation                 0x1978be388 -[__NSDictionaryM objectForKeyedSubscript:] + 184

2  CoreTelephony                  0x197f3b024 -[CTTelephonyNetworkInfo currentRadioAccessTechnology] + 188

3  RiverboatGambler               0x10295126c -[GADNetwork updateRadioAccessTechnology] + 216 (GADNetwork.m:216)

4  RiverboatGambler               0x1029510b4 __49-[GADNetwork enableRadioAccessTechnologyChecking]_block_invoke + 185 (GADNetwork.m:185)

5  Foundation                     0x198d2c850 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 24

6  Foundation                     0x198c19740 -[NSBlockOperation main] + 104

7  Foundation                     0x198d2eca4 __NSOPERATION_IS_INVOKING_MAIN__ + 24

8  Foundation                     0x198c193c8 -[NSOperation start] + 808

9  Foundation                     0x198d2f74c __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 24

10 Foundation                     0x198d2f1d4 __NSOQSchedule_f + 184

11 libdispatch.dylib              0x1975dffb8 _dispatch_block_async_invoke2 + 148

12 libdispatch.dylib              0x1975d1db0 _dispatch_client_callout + 20

13 libdispatch.dylib              0x1975df7ac _dispatch_main_queue_callback_4CF + 836

14 CoreFoundation                 0x19795911c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16

15 CoreFoundation                 0x197953120 __CFRunLoopRun + 2508

16 CoreFoundation                 0x19795221c CFRunLoopRunSpecific + 600

17 GraphicsServices               0x1af51c784 GSEventRunModal + 164

18 UIKitCore                      0x19a392ee8 -[UIApplication _run] + 1072

19 UIKitCore                      0x19a39875c UIApplicationMain + 168

20 RiverboatGambler               0x10238f6e8 main + 18 (FourCardPokerAchievementsEngine.swift:18)

21 libdyld.dylib                  0x1976126b0 start + 4

[Mobile Ads SDK Forum Advisor Prod]

Hi Riverboat,

Thank you for responding back to us. In looking back to see what has happened since last posted here. This issue should have been resolved when people updated to v8.1 as you will see by our release notes here . Also from the feedback I am seeing from our team, if needed you should also be able to roll back to 7.64 and the issue should not appear, but in general we would suggest updating to 8.1 or higher.