xcode 上传符号文件

Upload symbol files

提问by Zac

In my Firebase Crash Reporting page i can't find the full information of crashes (for example the number of row, the file and so on) . I thought it can be because it says

在我的 Firebase 崩溃报告页面中，我找不到崩溃的完整信息（例如行数、文件等）。我认为这可能是因为它说

Upload symbol file to symbolicate future stack traces for UUID ----***

上传符号文件以符号化 UUID 的未来堆栈跟踪 -- --***

telling me to

告诉我

Using the command line, navigate to your Xcode project folder and run the following: ./Pods/FirebaseCrash/batch-upload ----***

使用命令行，导航到您的 Xcode 项目文件夹并运行以下命令：./Pods/FirebaseCrash/batch -upload -- --***

Unfortunately when i try to execute that command in my Xcode project i get the following message:

不幸的是，当我尝试在我的 Xcode 项目中执行该命令时，我收到以下消息：

----***: warning: no executable or bundle Done.

----***：警告：没有可执行文件或捆绑包完成。

and nothing changes in firebase. Maybe it is because of bitcode enabled? How can i solve it?

Firebase 没有任何变化。也许是因为启用了位码？我该如何解决？

P.S. : I have replaced my UUID with ----*** for security reasons.

PS：出于安全原因，我已经用-- --***替换了我的 UUID 。

采纳答案by Chris Conway

This answer is if you're not using CocoaPods.

如果您不使用 CocoaPods，则此答案是正确的。

If you are not using CocoaPods you will need some files from the Pods directory that aren't included in the standard set of Firebase libraries they provide.

如果您不使用 CocoaPods，您将需要 Pods 目录中的一些文件，这些文件未包含在它们提供的标准 Firebase 库集中。

There are 5 files, pictured below:

有5个文件，如下图：

You will need batch-upload, dump_syms, upload-sym, upload-sym-util.bashand upload-sym.sh. You can retrieve these files from the FirebaseCrash Pod files.

你需要batch-upload，dump_syms，upload-sym，upload-sym-util.bash和upload-sym.sh。您可以从 FirebaseCrash Pod 文件中检索这些文件。

If you copy those into your project directory and replace the "${PODS_ROOT}"/FirebaseCrash/with the directory pointing to those files, it should work.

如果将它们复制到项目目录中并用"${PODS_ROOT}"/FirebaseCrash/指向这些文件的目录替换，它应该可以工作。

Note: I still have complications with this solution if I use a build server like Jenkins. Still some work to be done there.

注意：如果我使用像 Jenkins 这样的构建服务器，这个解决方案仍然很复杂。还有一些工作要做。

---

---

I found that this was required for my apps that don't use CocoaPods. While this might not be directly relevant to your own use, I figure at the very least I should include it for someone else trying to find the answer.

我发现这对于我不使用 CocoaPods 的应用程序是必需的。虽然这可能与您自己的使用没有直接关系，但我认为至少我应该将其包含在内，以供其他人尝试找到答案。

回答by Robert Menke

We currently have some problems with third-party shared libraries (dynamic frameworks), so if you are using a shared library things get difficult. Follow the instructions below but replace the path to the app's executable with the path to the shared library.

我们目前在第三方共享库（动态框架）方面存在一些问题，因此如果您使用共享库，事情就会变得困难。按照以下说明进行操作，但将应用程序可执行文件的路径替换为共享库的路径。

If not, then it is possible that the original executable from which the crash was reported has been lost. Even if it is rebuilt with the same sources, the LC_UUID field will change.

如果没有，那么报告崩溃的原始可执行文件可能已丢失。即使使用相同的源重新构建，LC_UUID 字段也会更改。

1. Verify that the UUID is correct for the executable:

   dwarfdump --uuid /path/to/your/build/area/MyApp.app/MyApp

   If none of the UUIDs match the missing one, then game over. Sorry. You can try to restore the executable from Time Machine, Carbonite, or whatever, but that's about it.

2. If one of the UUIDs matches (there is one per architecture), then you still have the original executable, but you are most likely missing the dSYM bundle. You can verify that the dSYM is missing:

   mdfind com_apple_xcode_dsym_uuids=UUID

   You should see no response.

3. Regenerate the dSYM bundle:

   dsymutil -o=upload.dSYM /path/to/your/build/area/MyApp.app/MyApp

4. Check to see that the dSYM bundle is registered:

   mdfind com_apple_xcode_dsym_uuids=UUID

   You should get one response back: the upload.dSYMyou just created.

   If you don't see it, give it a few seconds and try again.

5. Run batch-upload UUIDagain.

6. If it still doesn't work, you can get partial results by processing the executable itself. Run batch-upload/path/to/your/build/area/MyApp.app/MyAppto get partial symbolication.

1. 验证可执行文件的 UUID 是否正确：

   dwarfdump --uuid /path/to/your/build/area/MyApp.app/MyApp

   如果没有一个 UUID 与丢失的 UUID 匹配，则游戏结束。对不起。您可以尝试从 Time Machine、Carbonite 或其他任何东西恢复可执行文件，但仅此而已。

2. 如果其中一个 UUID 匹配（每个架构有一个），那么您仍然拥有原始可执行文件，但您很可能缺少 dSYM 包。您可以验证 dSYM 是否丢失：

   mdfind com_apple_xcode_dsym_uuids=UUID

   您应该看不到任何响应。

3. 重新生成 dSYM 包：

   dsymutil -o=upload.dSYM /path/to/your/build/area/MyApp.app/MyApp

4. 检查 dSYM 包是否已注册：

   mdfind com_apple_xcode_dsym_uuids=UUID

   你应该得到一个回应：upload.dSYM你刚刚创建的。

   如果你没有看到它，给它几秒钟，然后再试一次。

5. 再跑。batch-upload UUID

6. 如果它仍然不起作用，您可以通过处理可执行文件本身来获得部分结果。运行以获得部分符号化。batch-upload/path/to/your/build/area/MyApp.app/MyApp

回答by matt

In my case (WITHOUT COCOAPODS):

1) Import All files from directory "Crash"

在我的情况下（没有 COCOAPODS）：

1）从目录“崩溃”中导入所有文件

2) Add script into "Build Phases" Tab like this :

2）将脚本添加到“构建阶段”选项卡中，如下所示：

# Replace this with the GOOGLE_APP_ID from your GoogleService-Info.plist file
GOOGLE_APP_ID=1:xxxxxxxxxxxx:ios:xxxxxxxxxxxx

# Replace the /Path/To/ServiceAccount.json with the path to the key you just downloaded
"${SRCROOT}"/upload-sym "${SRCROOT}/*NameOfTargetDirectory*/ServiceAccount.json"

You need to change "NameOfTargetDirectory" in the script and it works!

您需要在脚本中更改“ NameOfTargetDirectory”并且它可以工作！