flutterfire_cli icon indicating copy to clipboard operation
flutterfire_cli copied to clipboard

[bug]: Crashlytics: upload-symbols runs forever and never exits

Open justChris opened this issue 2 months ago • 2 comments

Is there an existing issue for this?

  • [x] I have searched the existing issues.

CLI Version

1.3.1

Firebase Tools version

14.24.2

Flutter Doctor Output

[✓] Flutter (Channel stable, 3.38.1, on macOS 26.1 25B78 darwin-arm64, locale en-US) [485ms] • Flutter version 3.38.1 on channel stable at /Users/chris/development/flutter • Upstream repository https://github.com/flutter/flutter.git • Framework revision b45fa18946 (7 days ago), 2025-11-12 22:09:06 -0600 • Engine revision b5990e5ccc • Dart version 3.10.0 • DevTools version 2.51.1 • Feature flags: enable-web, enable-linux-desktop, enable-macos-desktop, enable-windows-desktop, enable-android, enable-ios, cli-animations, enable-native-assets, omit-legacy-version-file, enable-lldb-debugging

[✓] Android toolchain - develop for Android devices (Android SDK version 35.0.0) [1,730ms] • Android SDK at /Users/chris/Library/Android/sdk • Emulator version 36.2.12.0 (build_id 14214601) (CL:N/A) • Platform android-36, build-tools 35.0.0 • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java This is the JDK bundled with the latest Android Studio installation on this machine. To manually set the JDK path, use: flutter config --jdk-dir="path/to/jdk". • Java version OpenJDK Runtime Environment (build 21.0.8+-14196175-b1038.72) • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 26.1.1) [1,023ms] • Xcode at /Applications/Xcode.app/Contents/Developer • Build 17B100 • CocoaPods version 1.16.2

[✓] Chrome - develop for the web [6ms] • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Connected device (5 available) [9.6s] • sdk gphone64 arm64 (mobile) • emulator-5554 • android-arm64 • Android 16 (API 36) (emulator) • Chris’s iPhone (wireless) (mobile) • 00008130-000970383EE0001C • ios • iOS 26.1 23B85 • iPhone Air (mobile) • 6C81E7D0-CE56-4426-9F86-5F046B07E581 • ios • com.apple.CoreSimulator.SimRuntime.iOS-26-1 (simulator) • macOS (desktop) • macos • darwin-arm64 • macOS 26.1 25B78 darwin-arm64 • Chrome (web) • chrome • web-javascript • Google Chrome 142.0.7444.176

[✓] Network resources [252ms] • All expected network resources are available.

• No issues found!

Description

Debug Symbols are being created successfully and in debug mode, they are being uploaded to crashlytics successfully.

In release mode, when archiving, the spawned script by build phases upload-symbols never exits and becomes a zombi process.

So the dsym never reaches crashlytics.

I am not sure but it could be that this started happening when I updated to xcode 26.1.1

This is the output from flutterfire upload-crashlytics-symbols:

Running upload-symbols in Build Phase mode
Validating build environment for Crashlytics...
Validation succeeded. Symbol uploading will proceed in the background.
Running upload-symbols in Build Phase mode
Validating build environment for Crashlytics...
Validation succeeded. Symbol uploading will proceed in the background.

If I run the script manually, it crashes:

flutterfire upload-crashlytics-symbols --upload-symbols-script-path="/Users/chris/development/projects/testapp/ios/Pods/FirebaseCrashlytics/run" --platform=ios --apple-project-path="/Users/chris/development/projects/testapp/ios" --env-platform-name="iphoneos" --env-configuration="Release" --env-project-dir="/Users/chris/development/projects/testapp/ios" --env-built-products-dir="/Users/chris/Library/Developer/Xcode/DerivedData/Runner-anfkrgjcsbgdzhejjaiyomkhesst/Build/Intermediates.noindex/ArchiveIntermediates/Runner/BuildProductsPath/Release-iphoneos" --env-dwarf-dsym-folder-path="/Users/chris/Library/Developer/Xcode/DerivedData/Runner-anfkrgjcsbgdzhejjaiyomkhesst/Build/Intermediates.noindex/ArchiveIntermediates/Runner/BuildProductsPath/Release-iphoneos" --env-dwarf-dsym-file-name="Runner.app.dSYM" --env-infoplist-path="Runner/Info.plist" --default-config=default 

Unhandled exception:
Exception: 
#0      UploadCrashlyticsSymbols.run (package:flutterfire_cli/src/commands/upload_symbols.dart:387:7)
<asynchronous suspension>
#1      CommandRunner.runCommand (package:args/command_runner.dart:212:13)
<asynchronous suspension>
#2      main (file:///Users/chris/.pub-cache/hosted/pub.dev/flutterfire_cli-1.3.1/bin/flutterfire.dart:63:5)
<asynchronous suspension>

Steps to reproduce

  1. Create a new flutter project on xcode 26.1.1
  2. Setup crashlytics
  3. Run Debug Mode
  4. Archive app for release
  5. Force a crash

Expected behavior

Dsyms are being uploaded as it was before.

Screenshots

Image

Additional context and comments

No response

justChris avatar Nov 20 '25 11:11 justChris

Seems like this issue has been around for a while. My latest release from August/September shows missing dSYM files and the same issue is happening for me too...

flocbit avatar Nov 24 '25 17:11 flocbit

After hours of searching the web and talking to AI, this could be a race condition. This is what Gemini said:

Modern Xcode (versions 16 through 26) uses an aggressive parallel build system. It tries to run as many tasks as possible at the same time to speed up your build.

    Without Input Files: Xcode looks at your script and sees no dependencies. It assumes it can run this script immediately, often at the exact same time it starts generating the dSYM file.

        Result: The script runs, looks for the dSYM, finds it missing or incomplete (because it's still being built), and fails or uploads nothing.

    With Input Files: You explicitly tell Xcode, "This script needs Runner.app.dSYM."

        Result: Xcode pauses the script. It waits until the dSYM generation task marks itself as "Done." Only then does it trigger your script.

As soon as i set the input file to ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME} it started working again.

justChris avatar Nov 24 '25 21:11 justChris

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

github-actions[bot] avatar Dec 22 '25 21:12 github-actions[bot]