EXC_BREAKPOINT <编辑>如何调试？

Question

我们最近向我们的用户群发布了我们的应用程序，我们在Sentry中看到了一堆我们无法以任何逻辑方式调试的编辑异常。

这些异常似乎唯一的共同点是，当应用程序处于活动状态时，它们永远不会发生：

这些设备上的可用内存似乎非常低：

我们的一个理论是，由于可用内存不足，操作系统决定关闭所有后台应用程序。

但是，当我更倾向于认为我们在自己的代码中犯了错误时，这是​​一个很好的假设。

对于我的问题，我们将如何调试这些编辑的异常？我们是否有理由相信我们的应用程序在不活动时关闭并不值得关注？

Answer 1

Sentry的内部部署版本有几个与此特定问题相关的问题。根据Sentry团队的说法，这些将在即将发布的内部部署版本中修复。但总结一下。

首先，我们很难获得dSYM上传脚本的功能。提到的Fastlane车道here根本不起作用。调试符号下的Sentry接口中提示的bash脚本也没有。

使用sentry-cli（最新版本）的工作是什么，并且为我们的内部部署提高了我们的nginx服务器上传的可接受文件大小。但是在成功将我们的dSYMs文件实际显示在Sentry中后，我们遇到了更多问题。

我们遇到的问题如下：

1. A required debug symbol file was missing

  

@ johan12345很抱歉这么晚才回复你。我们已经验证了您的调试符号，并确认它们应该正确处理和符号化。您所指的问题已经在sentry-cli和Sentry中修复了一段时间，并将在下一个版本中提供。

     

我们一直在准备过去几个月的重大发布，这就是最近没有发布的原因。但是，由于我们已经收到了一些关于内部客户符号化的请求，我们将尽快推出新版本。但是，我不能给你一个确切的时间表，所以请继续关注。

     

同样，我很抱歉这可能造成的不便。

https://github.com/getsentry/sentry/issues/7595

1. Reprocessing 12 events …

  

有些用户报告有时会停留在重新处理上。主要发生在自我安装，但我们也有两个支持问题。

     

这似乎是由处理管道中的不良位置的内部服务器错误引发的。

     

相关：https://forum.sentry.io/t/stuck-there-are-x-events-pending-reprocessing/1518/6

https://github.com/getsentry/sentry/issues/5862

  

我们添加了一个名为＆＃34的新按钮;放弃所有＆＃34;可以在处理问题列表上方找到。   这将丢弃所有处理问题和相应的事件。   我们还在我们尚未修复的处理渠道中发现错误。   我现在将关闭此问题，并在以后链接有关处理错误的新问题。

     

所以我现在唯一可以建议的是基本上部署Sentry的主分支，因为我们的最后一个版本是在11月份，然后我们修复了一堆东西。

     

不确定我们是否会在Sentry 9之前发布新版本（仍需要一些时间）。

https://forum.sentry.io/t/ios-exceptions-shows-up-as-redacted/3681

TLDR：我们正在转向Crashlytics