Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[APMMeasurement didInitializeComponments] main thread hangs #10151

Closed
linziyiwj opened this issue Aug 30, 2022 · 14 comments
Closed

[APMMeasurement didInitializeComponments] main thread hangs #10151

linziyiwj opened this issue Aug 30, 2022 · 14 comments
Assignees

Comments

@linziyiwj
Copy link

Description

Sdk version:
Firebase 9.5.0
Google-Mobile-Ads-SDK 9.8.0
GoogleAppMeasurement: Firebase/GoogleAppMeasurement

We find the problems in hangs of Xcode 14.0 organizer, it hangs the main thread for a long time.

image

Reproducing the issue

No response

Firebase SDK Version

9.5.0

Xcode Version

13.4

Installation Method

CocoaPods

Firebase Product(s)

AB Testing, Analytics, Crashlytics, In-App Messaging, Performance, Remote Config

Targeted Platforms

iOS

Relevant Log Output

No response

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!
@google-oss-bot
Copy link

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

@rizafran
Copy link
Contributor

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

@morganchen12
Copy link
Contributor

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

@linziyiwj
Copy link
Author

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

@linziyiwj
Copy link
Author

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!!!

@paulb777
Copy link
Member

paulb777 commented Sep 1, 2022

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

@linziyiwj
Copy link
Author

@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

@paulb777
Copy link
Member

paulb777 commented Sep 2, 2022

cc: @htcgh

@tsunghung tsunghung self-assigned this Sep 3, 2022
@tsunghung
Copy link
Contributor

tsunghung commented Sep 3, 2022

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
Copy link
Contributor

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

@linziyiwj
Copy link
Author

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
Copy link
Author

@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>

@tsunghung
Copy link
Contributor

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

@paulb777 paulb777 added this to the Firebase 10 - M122 milestone Sep 19, 2022
@ncooke3
Copy link
Member

ncooke3 commented Oct 10, 2022

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

@ncooke3 ncooke3 closed this as completed Oct 10, 2022
@firebase firebase locked and limited conversation to collaborators Nov 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.