[firebase_crashlytics]: Generated "Crashlytics Upload Symbols" build phase has no DWARF input, so it can start before dsymutil finishes

Start with packages/firebase_crashlytics/firebase_crashlytics/ios/crashlytics_add_upload_symbols and inspect how it sets phase.input_paths and updates an existing stock phase; compare the macOS script, which the issue says has the same list. The issue names no test file, so first run the supplied generator command and inspect the generated Xcode project phase. Done means generated and updated phases include the DWARF file as an input, so the upload phase waits for it.

Is there an existing issue for this?

• I have searched the existing issues.

Which plugins are affected?

Crashlytics

Which platforms are affected?

iOS

Description

The Ruby script crashlytics_add_upload_symbols (run from the iOS and macOS podspecs) adds a build phase named [firebase_crashlytics] Crashlytics Upload Symbols to the Runner target. The inputPaths it writes do not include the DWARF file that dsymutil produces:

phase.input_paths = [
    "\"${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}\"",
    "\"${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/\"",
    "\"${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Info.plist\"",
    "\"$(TARGET_BUILD_DIR)/$(EXECUTABLE_PATH)\"",
    "\"$(PROJECT_DIR)/firebase_app_id_file.json\"",
]

Without …/Contents/Resources/DWARF/${PRODUCT_NAME} as an input, Xcode has no reason to wait for dsymutil to finish writing the DWARF file. The phase can start while that file is still 0 bytes.

Firebase's own list, Crashlytics/CrashlyticsInputFiles.xcfilelist in firebase-ios-sdk, has that entry (and no literal quotes):

$(TARGET_BUILD_DIR)/$(UNLOCALIZED_RESOURCES_FOLDER_PATH)/GoogleService-Info.plist
$(TARGET_BUILD_DIR)/$(EXECUTABLE_PATH)
${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}
${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Info.plist
${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${PRODUCT_NAME}
${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${PRODUCT_NAME}.debug.dylib

History: the DWARF entry (…/Contents/Resources/DWARF/${TARGET_NAME}) was replaced by …/Contents/ in a37965bea ("Modify input files for xcode15", 2023-08-02) and has not come back. The list is the same at tag firebase_crashlytics-v5.4.0 and on main.

What happened to us

On a CI machine (macOS 27, Xcode 27.0) every Release archive of our app hung in this phase until the build timed out. Timeline from our watchdog log (this run had the literal quotes removed, see the table below; the as-generated runs hung the same way):

dSYM generation started (after 212s)
Crashlytics phase started (after 213s)
HANG: xcodebuild still running after 720s
last script phase: PhaseScriptExecution [firebase_crashlytics] Crashlytics Upload Symbols

The phase started one second after dSYM generation started. At that moment the DWARF file in the dSYM was 0 bytes. upload-symbols does not fail on a 0-byte DWARF file: it waits forever at 0% CPU. That is a separate problem in upload-symbols itself.

On a developer Mac with the same Xcode (macOS 26.6) dsymutil finishes first, so the problem does not show locally. It is a race that depends on the machine.

What we tried (same app, same machine image, signed, upload on):

So the missing DWARF input is the cause; the quotes alone are not.

Expected: the generated phase waits for the dSYM's DWARF file before upload-symbols runs.

Actual: the phase has no dependency on the DWARF file, so on a slow or busy machine upload-symbols can run against an incomplete dSYM.

Reproducing the issue

1. Run the generator on any Xcode project with an app target (this is what pod install does for the iOS podspec):

   echo '{}' > firebase_app_id_file.json
   ruby crashlytics_add_upload_symbols -f -p . -n Runner.xcodeproj
   

   (script from packages/firebase_crashlytics/firebase_crashlytics/ios/, main, with the xcodeproj gem 1.28.1)

2. Open Runner.xcodeproj/project.pbxproj. The [firebase_crashlytics] Crashlytics Upload Symbols phase has the inputPaths shown above and none of them is the DWARF file.

3. To see the race, archive a Release build and log ls -l "${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/" at the start of the phase. On our CI machine the file is 0 bytes. On a fast local Mac it is usually complete.

We can't give a deterministic repro of the race itself. The missing dependency in step 2 is deterministic.

Firebase Core version

4.15.0

Flutter Version

3.47.6

Relevant Log Output

[diag] sw_vers: 27.0, Xcode 27.0 Build version 27A266a
[diag] starting xcodebuild archive ... -configuration Release -sdk iphoneos -destination generic/platform=iOS
[diag] dSYM generation started (after 212s)
[diag] Crashlytics phase started (after 213s)
[diag] HANG: xcodebuild still running after 720s
[diag] last script phase: PhaseScriptExecution [firebase_crashlytics]\ Crashlytics\ Upload\ Symbols

Flutter dependencies

No response

Additional context and comments

Suggested fix

• Replace input_paths with the entries from CrashlyticsInputFiles.xcfilelist (unquoted, including …/Contents/Resources/DWARF/${PRODUCT_NAME}).
• Existing projects keep the old list: when the script finds a stock phase it only rewrites shell_script and leaves input_paths alone. It could update input_paths there too. (Our phase was added in March 2025 and kept its original list.)
• The macOS script (macos/crashlytics_add_upload_symbols) has the same list.

Related

• invertase/flutterfire_cli#417 (closed, stale): upload-symbols runs forever; a commenter fixed it by adding the dSYM folder as an input and suspected the same race. That report uses the CLI's own phase, which had no inputs at all.
• invertase/flutterfire_cli#370 (closed): indefinite hang with a CLI phase whose inputPaths were empty.
• firebase/flutterfire#17862 (closed, redirected to the CLI repo): same symptom.
• firebase/firebase-ios-sdk#11159: a commenter notes that the DWARF file is not always generated yet when the script starts, and that the dSYM folder alone is not a safe input.
• None of them shows the DWARF file at 0 bytes or that upload-symbols hangs on it.