Crash - [FPRClient logTrace:]_block_invoke

[tamv-ika]

Description

Hi, we have an issue with the Firebase sdk. This issue already asked and mark as fixed on the version 8.6.0 in this issue: https://github.com/firebase/firebase-ios-sdk/issues/8545

But we're using version 8.15.0 and this crash still happen, could you help me to check this?

Here is my crash log:

Reproducing the issue

No response

Firebase SDK Version

8.15.0

Xcode Version

14.1

Installation Method

Swift Package Manager

Firebase Product(s)

Analytics, Crashlytics, Performance

Targeted Platforms

iOS

Relevant Log Output

Crashed: com.google.perf.sessionIds.trace

0  libobjc.A.dylib                0x2e5c objc_retain_x0 + 16
1  libobjc.A.dylib                0x2e5c objc_retain + 16
2  CoreFoundation                 0x71ffc __NSSingleObjectArrayI_new + 88
3  CoreFoundation                 0x5238 -[NSArray initWithArray:range:copyItems:] + 368
4  MyApp                       0x15753f0 __20-[FIRTrace sessions]_block_invoke + 239 (FIRTrace.m:239)
5  libdispatch.dylib              0x3fdc _dispatch_client_callout + 20
6  libdispatch.dylib              0x13574 _dispatch_lane_barrier_sync_invoke_and_complete + 56
7  MyApp                       0x1575344 -[FIRTrace sessions] + 238 (FIRTrace.m:238)
8  MyApp                       0x1563ae8 FPRGetTraceMetric + 286 (FPRNanoPbUtils.m:286)
9  MyApp                       0x1561250 __22-[FPRClient logTrace:]_block_invoke + 174 (FPRClient.m:174)
10 libdispatch.dylib              0x24b4 _dispatch_call_block_and_release + 32
11 libdispatch.dylib              0x3fdc _dispatch_client_callout + 20
12 libdispatch.dylib              0xb774 _dispatch_lane_serial_drain + 896
13 libdispatch.dylib              0xc1e0 _dispatch_lane_invoke + 384
14 libdispatch.dylib              0x16e10 _dispatch_workloop_worker_thread + 652
15 libsystem_pthread.dylib        0xdf8 _pthread_wqthread + 288
16 libsystem_pthread.dylib        0xb98 start_wqthread + 8

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

```json Replace this line with the contents of your Package.resolved. ```

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

```yml Replace this line with the contents of your Podfile.lock! ```

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[rizafran]

Thanks for reporting, @tamv-ika. Is the issue reproducible using the latest SDK version?

[tamv-ika]

Hi @rizafran, as I mentioned on the #10522, both issues are reported from firebase Crashlytics and run on version 8.15.0. And I havent update to the lastest SDK version. So I don't know does this issues exist in the lastest one.

[visumickey]

Thanks @tamv-ika for sharing the stack trace. Looking at the crashed line, Firebase performance does a copy of an object. It is hard to see a reason why this could lead to a crash (Probably copy of items could lead to a crash, but chances are really low I'm hoping).

• Similar to the other issue, can you provide the full stack trace of what other threads were doing at the time of the crash?
• Can you also provide some details about the iOS version where this issue happens more often?

[tamv-ika]

@visumickey, thanks for sharing the information. I don't have full snapshot of the application stack trace at the time of crash. I also look at the crashed line you found, and I did some investigation based on your theory of race condition. I did a little search and I saw that all the modifications of the activeSessions was made in a serial queue sessionIdSerialQueue except the creation is made in the callee thread. In the crashed line the result is also got from the sessionIdSerialQueue => difficult to have race condition here. But I've notice a thing, dispatch_queue is use in sync which mean it will put a task into the sessionIdSerialQueue and do a wait in the current callee queue => become a deadlock if these two queues are in the same runloop. But in the crash log above this deadlock didn't happen. So the problem is caused by the copy function. I can't go further :(.