Realm-cocoa: Crash in Table::find_first_string in RealmSwift v1.1.0, Swift 2.3

[jbrennan]

Goals

I'm getting a crash in Realm Swift while running our unit tests that I can't figure out. It seems to be consistently crashing for me on an iPhone 7, iOS 10 Simulator only (but a co-worker has it crashing on an iPhone 6s, iOS 10 Sim only, also consistently).

I'm in the process of migrating our app + pods for Xcode 8 + Swift 2.3. This issue does not occur for us in our previous version of the pod (we were using v0.102.0 previously).

Expected Results

Realm to not give an EXC_BAD_ACCESS.

Actual Results

The stack trace looks like:

Realm`realm::Table::find_first_string(unsigned long, realm::StringData) const + 27, 
    queue = 'NSOperationQueue 0x608000c35ee0 :: NSOperation 0x6080010512e0 (QOS: DEFAULT)',
    stop reason = EXC_BAD_ACCESS (code=1, address=0x98)
#0: Realm`realm::Table::find_first_string(unsigned long, realm::StringData) const + 27
#1: Realm`getRowForObjectWithPrimaryKey(info=0x00006100004c2cb8, primaryValue="211900625") + 325 at RLMObjectStore.mm:150
#2: Realm`createOrGetRowForObjectWithPrimaryKey(info=0x00006100004c2cb8, primaryValue="211900625", foundExisting=0x00007000015ae223) + 71 at RLMObjectStore.mm:224
#3: Realm`unsigned long createOrGetRowForObject<RLMAddObjectToRealm::$_0>(info=0x00006100004c2cb8, valueForProperty=(anonymous class) @ 0x00007000015adfb0, createOrUpdate=true, foundExisting=0x00007000015ae223) + 192 at RLMObjectStore.mm:249
#4: Realm`RLMAddObjectToRealm(object=0x00007fd61ebbb520, realm=0x0000610000cbf5c0, createOrUpdate=true) + 785 at RLMObjectStore.mm:295
#5: RealmSwift`Realm.add(object=0x00007fd61ebbb520, update=true, self=0x0000610000a285e0) -> () + 731 at Realm.swift:844
#6: RealmSwift`Realm.add<A where ...> (objects=<unavailable>, update=true, self=0x0000610000a285e0) -> () + 355 at Realm.swift:859

Getting a consistent crash in RLMObjectStore.mm line 150 in the call RLMStringDataWithNSString(primaryValue) (for RealmSwift version v1.1.0).

In my case, primaryValue is an NSString with a value of "211900625" and the property's name is canonicalIdentifier. (this code runs in the process of creating a new user, so this ID represents the user's ID).

Steps to Reproduce

I'm not quite sure yet how to isolate it, sorry.

Version of Realm and Tooling

ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G1004

/Applications/Xcode.app/Contents/Developer
Xcode 8.0.0
Build version 8A218a

/Users/jasonb/.rbenv/shims/pod
1.0.1
Realm (1.1.0)
RealmSwift (1.1.0)
RealmSwift (~> 1.1.0)

/bin/bash
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)


(not in use here)

/usr/bin/git
git version 2.7.4 (Apple Git-66)

[jbrennan]

As pointed out elsewhere, it's confusing that the stack trace doesn't mention RLMStringDataWithNSString but I _think_ that's because it's an inlined function.

[bdash]

From looking at the disassembly of Realm Core v1.5.0, used in Realm Swift v1.1.0, a faulting address of 0x98 suggests that Table::m_column is null, and the crash is occurring when Table::find_first_string calls Column::is_attached. I don't have any idea why Table::m_column could be null.

[jpsim]

Hi @jbrennan, is it possible for you to check with more recent versions of Realm (2.1.0 being the latest as of this writing) to see if this is still an issue? Trying to assess how relevant this crash is now, two months later.

[jpsim]

Could be related to realm/realm-core#1938

[bcapps]

Hey @jpsim, I just upgraded to 2.1.0 on a branch and still see this crash occurring, unfortunately.

[bradgmueller]

Hey all -

I ran into this same crash, same line, today. Was able to solve it, maybe it applies for you too.

Here was my setup:

• User signs in
• [RLMRealmConfiguration setDefaultConfiguration:myConfiguration]
• User uses app with defaultRealm
• User signs out
• [[NSFileManager defaultManager] removeItemAtPath:<path_from_my_config> error:nil]
• User signs in again
• [RLMRealmConfiguration setDefaultConfiguration:myConfiguration]
• App goes to add first object into Realm
• Bad Access Crash

I was able to repeat this consistently. Using the Profiler for Allocations, I tracked how many instances of RLMRealm existed. I noticed that after Signing Out, there was still 1 instance hanging around.

I found a retain cycle within my app, causing a view controller to hang around, and that controller was holding strongly some RLMObject subclasses.

When I fixed the retain cycle, I checked the Profiler again, and upon Signing Out, all RLMRealm instances were deallocated. Then, going to Sign In again, there was no crash.

--
Also, using Realm 2.5.1, Obj-C, Xcode 8.3.1, ran on iOS 10 Simulator

[jpsim]

@bradgmueller what you shared makes total sense.

In general, please avoid deleting Realm files if they're still being accessed.

[jpsim]

We just released Realm Objective-C & Swift 2.8, which includes a number of bug fixes that might have addressed the issues reported in this thread. I'd appreciate if everyone could update to that version (or later by the time you read this) and let us know if you're still experiencing this crash in a fresh environment, as in creating a Realm file from scratch.

Thanks for your help and patience as we work to resolve this!

[rromanchuk]

Regarding:
unsigned long realm::Table::find_first<realm::StringData>(unsigned long, realm::StringData) const + 32

Just want to give a heads up because i've seen this myself and see a hodgepodge of tickets around this exception. I noticed a trend of people reporting around deleting, which also is usually done around "logging the user out" paradigm, cleaning up the object graph etc. This was also where I was seeing issue, and very hard to reproduce.

Today i found a cache expiration method that was unintentionally destroying the realm file, which now makes a lot of sense. This also leads me to believe that other users with this problem that are "cleaning up the client" are also unintentionally deleting this file.

For search posterity. If you are seeing this crash, grep your project for anything using NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true) and make sure you aren't unintentionally purging realm.

[bdash]

We've not seen any further reports of this, and the few reports we received since the issue was originally filed were traced back to the Realm file being removed while it was still open. I'm going to consider this as fixed.

[RetVal]

I have the crash, the member of table is nil in the RLMClassInfo.