EXC_BAD_ACCESS issue need advice

Thanks for the post, my guess here is your process is called KSCrash? The crash file should be posted as an attachment to be able to analyze.

Kindly submit a comprehensive crash report, adhering to the guidelines outlined in Posting a Crash Report.

https://developer.apple.com/forums/thread/688669

As you said, the error typically indicates that your application is trying to access memory that has already been deallocated or is otherwise invalid. Although you mentioned using Address Sanitizer, double-check your configuration to ensure it's correctly enabled. Sometimes, specific project settings might prevent tools from working as expected. If you're using collections that hold objects, ensure they are not being modified. Use or breakpoints to trace object lifetimes and ensure they are being deallocated when expected. This can help pinpoint where the object is being released prematurely. If you're using third-party libraries, ensure they are up-to-date, as bugs in libraries can manifest similarly. However it seems like the crash is in the main binary. In Xcode, use the "Leaks" and "Zombies" instruments to track over-released objects.

I’m looking forward to your crash file! But nothing better than being able to reproduce it!

Albert Pascual
  Worldwide Developer Relations.

Thank you for your guidance!

Unfortunately, we have been unable to reproduce the crash internally, and it does not appear in Xcode Organizer. All occurrences were reported from production devices, so we do not have access to the corresponding .ips files.

However, we can provide the full stack trace from Firebase Crashlytics if that would be helpful.

[Different DTS engineer here; I’m picking up this thread because it’s directly aligned with my area of expertise.]

it does not appear in Xcode Organizer.

Right. The issue here is that you have a third-party crash reporter installed and it’s failing to preserve the Apple crash report. Let’s look at the backtrace in your first post:

Crashed: com.apple.main-thread
0  KSCrash                  … ksmemory_notifyUnhandledFatalSignal + 12
1  KSCrash                  … handleSignal + 100
2  libsystem_platform.dylib … _sigtramp + 56
3  libsystem_kernel.dylib   … mach_msg2_internal + 76
4  libsystem_kernel.dylib   … mach_msg_overwrite + 428
5  libsystem_kernel.dylib   … mach_msg + 24
6  CoreFoundation           … __CFRunLoopServiceMachPort + 160
7  CoreFoundation           … __CFRunLoopRun + 1188
8  CoreFoundation           … _CFRunLoopRunSpecificWithOptions + 532
9  GraphicsServices         … GSEventRunModal + 120
10 UIKitCore                … -[UIApplication _run] + 792

Frames 10 through 3 are all standard UIKit stuff, where UIKit is blocked within the kernel waiting for an event to come in. Frame 2 indicates that the process has handled a single. This is bad because either:

• The crash reporter is reporting the crash on the wrong thread, which is a common failure mode for third-party crash reporters.
• Or its failing to backtrace across a cross signal handler stack frame, which is another common failure mode (partly because it’s there’s no good way to do it).

I go into a lot more detail about these challenges in Implementing Your Own Crash Reporter.

Given the above, your crash reports are not actionable. My advice is that you remove your third-party crash report so that you get trustworthy Apple crash reports. If you can post one of that, ideally one in JSON (.ips) format, I’d be happy to take another look.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"