Search code examples
iosswiftsentry

EXC_BREAKPOINT<redacted> how to debug?

We've recently released our app to our userbase and we are seeing a bunch of redacted exceptions in Sentry that we can't debug in any logical way.

The only thing these exceptions seem to have in common is that they never happen when the application is active:

enter image description here

And the available memory seems to be very low on these devices:

enter image description here

One theory we have is that the OS decides to close any background applications due to low memory available.

But it's quite a assumption to make at these point when I'm more inclined to believe we have made a mistake in our own code.

To my questions, how would we go about debugging these redacted exceptions? Are we right to believe that our app being closed when it's not active is no cause for concern?

Solution

  • The on-premise version of Sentry have several issues related to this specific problem. According to the Sentry team these will be fixed in a upcoming release for the on-premise version. But to summarize.

    At first we had difficulties getting the upload scripts for the dSYMs to work. The Fastlane lane mentioned here did not work at all. Neither did the bash script that was prompted in the Sentry interface under debugging symbols.

    What did work was using the sentry-cli (latest version) and bumping up the accepted file size for upload on our nginx server for our on premise. But after successfully getting our dSYMs file to actually show up in Sentry we had more problems.

    The issues we've encountered are listed below:

    1. A required debug symbol file was missing

    @johan12345 Sorry for getting back to you so late. We've verified your debug symbols and can confirm they should process and symbolicate correctly. The issue you are referring to has been fixed a while back in both sentry-cli and sentry and will be available with the next release.

    We have been preparing a major launch over the last couple of months which is why there have been no releases recently. However, since we've received a couple of requests regarding symbolication for on-premise customers, we will try to push a new release out soon. I cannot give you an exact timeline, though, so please stay tuned.

    Again, I'm very sorry for the inconvenience this might have caused.

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

    1. Reprocessing 12 events …

    Some users are reporting sometimes to be stuck on reprocessing. Mostly happens with self-installations but we also had two support issues.

    This seems to be triggered by internal server errors in the processing pipeline in bad places.

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

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

    We've added a new button called "Discard all" which can be found above your processing issues list. This will discard all processing issues and the corresponding events. We've also found an error in our processing pipeline we've yet to fix. I will close this issue for now and link new issues regarding processing errors later.

    So the only thing I can advise you right now is basically deploy the master branch of Sentry because our last release was in November and we fixed a bunch of stuff since then.

    Not sure if we release a new version before Sentry 9 (which still needs some time).

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

    TLDR: We are switching to Crashlytics