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

Thanks for reaching out, @linziyiwj. Could you provide the detailed steps in reproducing the issue as well as the complete stack trace?

Looks like the lock is necessary for this initialization logic, but we could potentially speed it up by using os_unfair_lock.

Thanks for reaching out, @linziyiwj. Could you provide the detailed steps in reproducing the issue as well as the complete stack trace?

@rizafran Unfortunately I have not been able to reproduce this block yet.
It is only reported in Xcode hangs. And only the above stack information

Looks like the lock is necessary for this initialization logic, but we could potentially speed it up by using os_unfair_lock.

@morganchen12 Sorry, I don't quite understand it. Can you explain it in detail. Thank you very much!!!

@linziyiwj I believe @morganchen12 was talking about a possible change in our internal implementation.

@linziyiwj I believe @morganchen12 was talking about a possible change in our internal implementation.

@paulb777 Please ask when will the version be updated to deal with this problem，Hope to have a solution as soon as possible

cc: @htcgh

Hi @linziyiwj, could you please provide all stack traces, including all other threads? It would help us to know where our internal worker thread is blocked. Thanks.

@linziyiwj
Just want to be sure, it's not a dead lock, right? It's just that the main thread gets blocked for 1 second, right? Please correct me if I misunderstood.
It seems that the worker thread holds the lock while initializing internal components, and the main thread is waiting for the initialization finished.
One quick suggestion, you may want to call FirebaseApp.configure() as soon as possible to allow FirebaseAnalytics initialize earlier and unblock the main thread sooner.

Hi @linziyiwj, could you please provide all stack traces, including all other threads? It would help us to know where our internal worker thread is blocked. Thanks.

@tsunghung Unfortunately I have not been able to reproduce this block yet.
It is only reported in Xcode hangs. And only the above stack information

@linziyiwj Just want to be sure, it's not a dead lock, right? It's just that the main thread gets blocked for 1 second, right? Please correct me if I misunderstood. It seems that the worker thread holds the lock while initializing internal components, and the main thread is waiting for the initialization finished. One quick suggestion, you may want to call FirebaseApp.configure() as soon as possible to allow FirebaseAnalytics initialize earlier and unblock the main thread sooner.
@tsunghung yes, It's just that the main thread gets blocked for 1 second. And We called [FIRApp configure] when - (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary<UIApplicationLaunchOptionsKey,id> *)launchOptions on the main thread , No lock held

@linziyiwj
Author
linziyiwj commented 7 minutes ago
Hi @linziyiwj, could you please provide all stack traces, including all other threads? It would help us to know where our internal worker thread is blocked. Thanks.

@tsunghung Unfortunately I have not been able to reproduce this block yet.
It is only reported in Xcode hangs. And only the above stack information

@linziyiwj

Add heading textAdd bold text, <Cmd+b>Add italic text, <Cmd+i>

According to the call stack, we created a patch, which will be released in Firebase 10.0. Hopefully, it would fix this issue.

Hi everyone, Firebase 10 has been released and should resolve this issue. Please don't hesitate to reach out if the issue persists.