Apologies for the delay, and thank you for the information and thoughts you have provided! I do have some clarifying questions about how to continue, plus some additional information that may help as well. First, I am trying to reconcile what appears to be a contradiction between the concept that any code change has the potential to move/eliminate/introduce a crash by “rearranging the internal details of our code”, and that one way to pinpoint the crash is to add logging, which is itself a code change that will “rearrange” things. I noticed that you specifically said "carefully added” logging - by that do you mean making sure the logging doesn’t somehow cause a “rearrangement” of the internal details of the code? If so, how does one go about doing that? Next, I am still trying to understand how a particular arrangement of our code can cause NULL to be “run”. Is there a contrived code example of how to accomplish this if for some reason one wanted to cause such a crash? If so, I am hoping that having an understanding of how this can actually occur will allow for better analysis of our code, and ideally detection of the true source of these crashes. Finally, we discovered a new-to-us option when stepping after hitting a breakpoint (step into instruction, holding down ctrl). After placing a breakpoint on the line where Xcode says the app crashes in our code, stepping into the instructions, and stepping into instruction repeatedly for a while (~25 times), it will eventually crash and show error: memory read failed for 0x0. See attached screenshots of the instructions that are executed right before the crash, and then the memory read failed message. Is this a clue worth pursuing? Thank you again for all of your assistance thus far!

Thank you for your response! Attached are some crash reports that represent attempts to merge in two separate branches that take our relatively stable (not crashing in the ways described above) main branch and introduce (or reintroduce) the observed crashes. Also, ASan is enabled for two out of four of the reports (one per branch) and disabled for the others. Did you try doing this incrementally? If you have a bunch of them, it’d be interesting to see which combinations do and don’t reproduce the problem. I will try this, but one of the primary issues with tracking these crashes down has been not knowing if/when they are truly eliminated as they tend to come and go after minimal code changes. It seems that almost any change to the code, or which files/libraries/frameworks are included in the build will change how the crashes manifest, or in some cases do not manifest. This is a bit of a long shot, but are there any things in particular (in crash reports or otherwise) we can look for in the future that would indicate this issue has been resolved other than the lack of crashes? Crash Report 1 Crash Report 2 Crash Report 3 Crash Report 4