firebase-ios-sdk icon indicating copy to clipboard operation
firebase-ios-sdk copied to clipboard

Crash - [FPRClient logTrace:]_block_invoke

Open tamv-ika opened this issue 3 years ago • 5 comments

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

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

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

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

tamv-ika avatar Nov 24 '22 10:11 tamv-ika

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

google-oss-bot avatar Nov 24 '22 10:11 google-oss-bot

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

rizafran avatar Nov 24 '22 14:11 rizafran

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.

tamv-ika avatar Nov 24 '22 16:11 tamv-ika

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?

visumickey avatar Dec 08 '22 22:12 visumickey

@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 :(.

tamv-ika avatar Dec 09 '22 02:12 tamv-ika