Closed kenji21 closed 1 year ago
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
Hey @kenji21, are you trying this out on a really large app? upload-symbols
should run for a fairly short time on small apps, but can take longer on larger apps.
The reason we don't tell devs to check the "For install builds only" option is because many devs want crashes to show up in development, and first time onboarding requires upload-symbols
to succeed so developers can make sure everything is set up correctly.
Using the run
script makes upload-symbols
run in the background. If you'd like it to run synchronously you can use:
${PROJECT_DIR}/vendor/FirebaseCrashlytics/upload-symbols --build-phase
Sure the project is 15k lines of swift. I don't want my unit tests to be runned slower (neither IBInspectable/SwiftUI previews builds)... I think it is wasteful to upload symbols on each debug build... maybe you should just mention the checkbox in your README
I apparently reported the same issue over here: https://github.com/firebase/firebase-unity-sdk/issues/81
However, with Unity, there is always a huge amount of il2cpp generated code and the issue is not so much the time it takes at 100% cpu but the amount of memory it fills. After a few seconds it fills all remaning memory available on my machine. It seems to not be limited to a resonable amount regarding how much memory the system has. It quickly makes the system unusable and even stalls the mouse cursor meaning upload-symbols can't do it's job because we have to kill it manually every time.
The reason we don't tell devs to check the "For install builds only" option is because many devs want crashes to show up in development, and first time onboarding requires
upload-symbols
to succeed so developers can make sure everything is set up correctly.
OK, then for "Debug builds", maybe you should check if the scheme has the debugger unticked (which is enabled by default), and Xcode will show the stack trace while debugging, so useless to upload symbols for such a build :
The Xcode project is generated, so anything that I change will be overridden the next time. The issue is not that upload-symbols is run, the issue is that it takes too much memory and cpu for big projects. It also doesn't do that every time, sometimes it is done without me noticing.
It also doesn't do that every time, sometimes it is done without me noticing.
random issue, hardest one to fix, 100% cpu means an infinite loop, but why such a loop happens ? can it be caused by a clean of the build folder (e.g. dSYM disappearing from disk during upload) ?
maybe gathering a sample (from Activity Monitor) could give some clue
For folks running into this, is it the case that the tool is completing the upload eventually, or is it really stuck in an infinite loop?
I'm no longer working on the project but what I've encountered was that it was staying at 100% for many minutes - waiting for it to finish was not realistically possible though as everything froze when the memory was used up. In order to reproduce, I recommend trying a default Unity sample project with Firebase added and just build it a few times.
It seems it may still be an issue in https://github.com/firebase/firebase-ios-sdk/issues/11159. I'm going to close this and continue the investigation in the new issue
Step 0: Are you in the right place?
firebase
tag.[REQUIRED] Step 1: Describe your environment
Swift Package Manager
[REQUIRED] Step 2: Describe the problem
Steps to reproduce:
What happened? How can we make the problem occur? Just built & run project test target ten times in a row (or maybe having designable in the project could do this)
If you have a downloadable sample project that reproduces the bug you're reporting, you will likely receive a faster response on your issue.
Relevant Code:
Ask people to tick the install only checkbox in the build phase, or better: determine if a build is an Archive one (uploading to the store... so we really need to upload symbols...) maybe like this (early exit for our linter script here):
As I was building for testing, App under unit test is correctly build, so the script phase was called