SIGSEGV on high sierra without a stacktrace

Question

Our app has started crashing for some users only on macOS 10.13.6 with the following crash logs. This doesn't tell us much. We've tried making several tweaks and nothing's helping. How do we figure out to do when we have no access to the user's machine? They've tried resetting the app, rebooting, re-installing etc but nothing helps.

We haven't received complaints for any other version of macOS. Have tried enabling zombies as well as all the other memory related debugging options within Xcode and nothing's coming up (when testing on macOS 11). We cannot build on 10.13 as our code requires Xcode 12.

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000103e00cebec8
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

VM Regions Near 0x103e00cebec8:
    CoreAnimation 0000000125666000-0000000125f1f000 [ 8932K] rw-/rwx SM=PRV
-->
    MALLOC_NANO 0000600000000000-0000600001e00000 [ 30.0M] rw-/rwx SM=PRV

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff57f9b184 objc_release + 36
1 libobjc.A.dylib 0x00007fff57f9c087 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 817
2 com.apple.AppKit 0x00007fff2e34039b __37+[NSDisplayCycle currentDisplayCycle]_block_invoke + 244
3 com.apple.QuartzCore 0x00007fff3bff8877 CA::Transaction::run_commit_handlers(CATransactionPhase) + 49
4 com.apple.QuartzCore 0x00007fff3bff7339 CA::Transaction::commit() + 171
5 com.apple.AppKit 0x00007fff2eaf8a72 __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke + 283
6 com.apple.CoreFoundation 0x00007fff30c88097 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
7 com.apple.CoreFoundation 0x00007fff30c87fbf __CFRunLoopDoObservers + 527
8 com.apple.CoreFoundation 0x00007fff30c6a538 __CFRunLoopRun + 1240
9 com.apple.CoreFoundation 0x00007fff30c69dd3 CFRunLoopRunSpecific + 483
10 com.apple.HIToolbox 0x00007fff2ff54d96 RunCurrentEventLoopInMode + 286
11 com.apple.HIToolbox 0x00007fff2ff54b06 ReceiveNextEventCommon + 613
12 com.apple.HIToolbox 0x00007fff2ff54884 _BlockUntilNextEventMatchingListInModeWithFilter + 64
13 com.apple.AppKit 0x00007fff2e201a3b _DPSNextEvent + 2085
14 com.apple.AppKit 0x00007fff2e997e34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044
15 com.apple.AppKit 0x00007fff2e1f684d -[NSApplication run] + 764
16 com.apple.AppKit 0x00007fff2e1c5a3a NSApplicationMain + 804
17 libdyld.dylib 0x00007fff58bc4015 start + 1

Answer 1

This turned out to be a nightmare as we spent over 3 days, trying 40 or so attempts. Nothing worked. It turned out to be a constraint on the cell's textField that we were removing and re-creating inside updateConstraints() . Only on macOS 10.13, this results in releasing the textField too somehow. The solution was to store the previous constraints in an ivar so that there's still a strong reference to the control in order to prevent it from being released.