[firebase_crashlytics]: Generated "Crashlytics Upload Symbols" build phase has no DWARF input, so it can start before dsymutil finishes
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 75/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Área
- build-system, devtools
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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):
| Phase inputs | DWARF size at phase start | Result |
|---|---|---|
| As generated | 0 bytes | hang (every run) |
| Literal quotes removed, nothing else | 0 bytes | hang |
Quotes removed + …/Contents/Resources/DWARF/${PRODUCT_NAME} added |
29.7 MB | uploaded in about 15 s |
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
-
Run the generator on any Xcode project with an app target (this is what
pod installdoes 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 thexcodeprojgem 1.28.1) -
Open
Runner.xcodeproj/project.pbxproj. The[firebase_crashlytics] Crashlytics Upload Symbolsphase has theinputPathsshown above and none of them is the DWARF file. -
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_pathswith the entries fromCrashlyticsInputFiles.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_scriptand leavesinput_pathsalone. It could updateinput_pathsthere 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-symbolsruns 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
inputPathswere 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-symbolshangs on it.
- Lenguaje dominante
- Dart
- Estrellas
- 9.3k
- Forks
- 4.1k
- Merge medio
- 1 d 16 h
- PR fusionados (30 d)
- 73
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de firebase/flutterfire
-
🚀 [firebase_core] Bump Firebase JS SDK (13.1.0 → 13.2.0)Posiblemente ocupada @SelaseKay la tomó hoy. AbiertoNeeds Attention type: enhancement
Dificultad 1/5 Menos de una hora Aptitud para principiantes 25/100
firebase/flutterfire#18902 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
[firebase_messaging]: Android: dismissing a notification delivers an empty RemoteMessage to onMessage (Firebase's NOTIFICATION_DISMISS broadcast is read as a message)Posiblemente ocupada @akashdh11 la tomó hace 1 día. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 38/100
firebase/flutterfire#18897 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Needs Attention type: bug
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
firebase/flutterfire#18894 · 1 comentario · 3 reacciones ·
Los mantenedores suelen responder en 1 día
-
Needs Attention platform: web plugin: auth type: bug
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
firebase/flutterfire#18888 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
[cloud_firestore][Windows] transaction.get() after a transaction timeout uses a destroyed Transaction (Windows counterpart of #18666 / #18755)Posiblemente ocupada @SelaseKay la tomó hace 6 días. AbiertoNeeds Attention platform: windows plugin: cloud_firestore reproduced type: bug
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
firebase/flutterfire#18883 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de firebase/flutterfire
Issues similares
-
Bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
fossasia/badgemagic-app#2034 ·
Los mantenedores suelen responder en 1 día
-
effort
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
berkmancenter/frankly#742 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
google/protobuf.dart#1111 ·