Crashing when attempting to write to realm - swift

Question

I have an app that takes recordings of passing vehicles and information about them. A client of ours is experiencing a crash when using the app, but I can't find the source. This is the report that I get from Crashlytics:
Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000098
Crashed: com.apple.main-thread
0 Realm 0x100d2f298 realm::Table::get_link_target(unsigned long) + 28
1 Realm 0x100b046f0 _ZZZN12_GLOBAL__N_110makeSetterIU8__strongP13RLMObjectBaseS3_EEP11objc_objectP11RLMPropertyEUb1_ENKUlvE_clEv (bind_ptr.hpp:186)
2 Realm 0x100b046f0 _ZZZN12_GLOBAL__N_110makeSetterIU8__strongP13RLMObjectBaseS3_EEP11objc_objectP11RLMPropertyEUb1_ENKUlvE_clEv (bind_ptr.hpp:186)
3 Realm 0x100b0462c ___ZN12_GLOBAL__N_110makeSetterIU8__strongP13RLMObjectBaseS3_EEP11objc_objectP11RLMProperty_block_invoke_2 (RLMAccessor.mm:313)
4 App Name 0x10070a398 SurveyController.(selected(button : RadioButton, in : RadioGroup) -> ()).(closure #1) (Survey Controller.swift:170)
5 RealmSwift 0x1007ee1e4 Realm.write(() throws -> ()) throws -> () (Realm.swift:155)
6 App Name 0x10070b200 specialized SurveyController.selected(button : RadioButton, in : RadioGroup) -> () (Survey Controller.swift:169)
7 App Name 0x10070a64c #objc SurveyController.selected(button : RadioButton, in : RadioGroup) -> () (Survey Controller.swift)
8 App Name 0x100715b24 specialized RadioGroup.buttonTapped(UITapGestureRecognizer) -> () (Radio Group.swift:77)
9 App Name 0x100715028 #objc RadioGroup.buttonTapped(UITapGestureRecognizer) -> () (Radio Group.swift)
10 UIKit 0x18e4f66e8 -[UIGestureRecognizerTarget _sendActionWithGestureRecognizer:] + 64
11 UIKit 0x18ea633b4 _UIGestureRecognizerSendTargetActions + 124
12 UIKit 0x18e658e38 _UIGestureRecognizerSendActions + 320
13 UIKit 0x18e4f5740 -[UIGestureRecognizer _updateGestureWithEvent:buttonEvent:] + 764
14 UIKit 0x18ea54bd4 _UIGestureEnvironmentUpdate + 1096
15 UIKit 0x18e4ef4d8 -[UIGestureEnvironment _deliverEvent:toGestureRecognizers:usingBlock:] + 404
16 UIKit 0x18e4ef010 -[UIGestureEnvironment _updateGesturesForEvent:window:] + 276
17 UIKit 0x18e4ee874 -[UIWindow sendEvent:] + 3132
18 UIKit 0x18e4ed1d0 -[UIApplication sendEvent:] + 340
19 UIKit 0x18ecced1c __dispatchPreprocessedEventFromEventQueue + 2340
20 UIKit 0x18ecd12c8 __handleEventQueueInternal + 4744
21 UIKit 0x18ecca368 __handleHIDEventFetcherDrain + 152
22 CoreFoundation 0x1846b3404 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
23 CoreFoundation 0x1846b2c2c __CFRunLoopDoSources0 + 276
24 CoreFoundation 0x1846b079c __CFRunLoopRun + 1204
25 CoreFoundation 0x1845d0da8 CFRunLoopRunSpecific + 552
26 GraphicsServices 0x1865b5020 GSEventRunModal + 100
27 UIKit 0x18e5ed758 UIApplicationMain + 236
28 App Name 0x100701994 main (Image Controller.swift:15)
29 libdyld.dylib 0x184061fc0 start + 4
Line 4, SurveyController.(selected(button : RadioButton, in : RadioGroup) -> ()).(closure #1) (Survey Controller.swift:170) is where I'm assuming the cause of the issue if coming from. This is that block of code:
vehicleGroup.clearSelection() // Line 155
...
func selected(button: RadioButton, in group: RadioGroup) {
if group == vehicleGroup {
let vehicle = realm.objects(Vehicle.self).filter("value = \(button.tag)").first
do {
try realm.write {
recording.vehicle = button.isSelected ? vehicle : nil // Line 170
}
} catch {
record(error: error)
}
}
...
}
// Allows parent controllers to remove selections and reset the view.
func clearSelection() {
for button in buttons {
button.isSelected = false
}
}
Some additional details from the client:
They usually have a few hundred recording made by the time it crashes, but not always. It doesn't always crash when they have that many recordings.
The crash usually kicks them back a screen in the app, but most recently closed the entire thing. I did add the do try catch blocks before the most recent crash, so it might have crashed the whole thing from that, but I thought those would help keep the app open.
What is the cause for the crash? According to Crashlytics, the device still has plenty of RAM left, so I assume it's not a memory leak. Also, like I said, this doesn't happen every time they have a large number of recordings.