[Bug] High CPU utilisation after authentication when running in sandbox on desktop (macOS)

[infiniteloopunroll]

[REQUIRED] Please fill in the following fields:

• Pre-built SDK from the website or open-source from this repo: Pre-built
• Firebase C++ SDK version: 9.3
• Problematic Firebase Component: Auth (Auth, Database, etc.)
• Other Firebase Components in use: Firestore (Auth, Database, etc.)
• Platform you are using the C++ SDK on: Mac ARM64 & x86 (Mac, Windows, or Linux)
• Platform you are targeting: Desktop (iOS, Android, and/or desktop)

[REQUIRED] Please describe the issue here:

When running the Firebase C++ SDK in a sandboxed app on macOS 12.5, high CPU utilisation is observed after authentication succeeds. Without sandboxing enabled, the issue does not occur.

Steps to reproduce:

Follow these steps to set up a test project that reproduces the issue. Or use the attached test project below.

1. Include Firebase Auth in a C++ or Objective-C++ class and implement an email + password authentication step.
2. Create an Xcode project with the template macOS → Application → App (Interface XIB, in order to select language Objective-C). Add your C++/Objective-C++ class to this project and the app target.
3. Under project → targets → $appname, add firebase_auth.framework (from fb_cpp_sdk/frameworks/darwin/universal/ in the pre-built C++ SDK folder) to the section "Frameworks, Libraries and Embedded Content", with the option Embed & Sign selected. Also add the other macOS dependencies here (CoreFoundation, Foundation, GSS, Kerberos, libpthread, Security and SystemConfiguration. Keep the standard value for embedding, Do not Embed).
4. Check that the frameworks in fb_cpp_sdk/frameworks/darwin/universal/ either contain all headers (four header files are missing from the v9.3 download in fb_cpp_sdk/frameworks/darwin/universal/firebase.framework/Headers/) or manually add the project header search path for fb_cpp_sdk/include/.
5. The project template contains the file $appname.entitlements. Make sure that the value for key "Sandboxing enabled" in this property list file is set to YES, in order to create a sandboxed app. Additionally, set both the com.apple.security.network.client and server values to YES, in order to allow network access.
6. Build the app and run it, then sign in using email + password.
7. As soon as the authentication succeeds, four Firebase worker threads keep running at full CPU utilisation. This can be checked in the debug navigator of Xcode when selecting CPU (displays about 400% usage continuously).

Expected outcome: The worker threads should use minimal CPU resources and sleep whenever possible.

8. (Optionally) Go back to the entitlements file and set "Sandboxing enabled" to NO, in order to deactivate sandboxing. The issue should no longer occur after clean build products and rebuild in Xcode, when running the app again and signing in.

Have you been able to reproduce this issue with just the Firebase C++ quickstarts ?
What's the issue repro rate? (eg 100%, 1/5 etc)

Yes, happens with any sandboxed Mac app build (100%).

What happened? How can we make the problem occur?
This could be a description, log/console output, etc.

As soon as the authentication succeeds, four Firebase worker keep running at full CPU utilisation.
This is mostly due to firebase::scheduler::Scheduler::WorkerThreadRoutine. This can be verified using Instruments, when sampling the running app.

Expected outcome: The worker threads should use minimal CPU resources and sleep whenever possible.

[infiniteloopunroll]

Here is a test project set up as described above, that allows for easy reproduction of the issue on Mac.
high cpu usage test project.zip

[chkuang-g]

Hi @infiniteloopunroll

Thank you for reporting.

Does this occur to you if Sandboxing is NOT enabled?

The first thing come to my mind is that Firebase Auth SDK attempting to store the auth token in macOS Keychain in that scheduler thread. I am not sure if this would work properly in a sandbox environment. Are you able to enable keychain in this environment?

Another possibility is when Firestore is trying to store persistent data under ~/.firebase/ but unable to access it.

Could you verify if these are the case? Also, are you able to provide the full callstack of those threads using lldb and bt all?

Thank!
Shawn

[google-oss-bot]

Hey @infiniteloopunroll. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[triplef]

Thanks for your feedback @chkuang-g! Due to summer vacations we need a bit more time getting back to you on this. Please don't close just yet. 🙏

[infiniteloopunroll]

Hi @chkuang-g, thanks for reaching out for further information. This issue is very important to me.

Here is what I can tell you right now:

• Yes, when sandboxing is disabled, this does not occur and everything works as expected.
• When sandboxed, Keychain access still seems to work and it stores FB credentials in the default keychain successfully.
• Access to ~/library/Application Support/ does also work in the sandboxed app and the SDK uses the correct subfolders in the app's container folder, when needed.

Unfortunately I can't provide the full call stack right now but will follow up in a couple of days, if it is still helpful.

Best,
Robin