Realm-cocoa: Invalid pointer dequeued from free list

[mrh-is]

Goals

Get an object out of Realm

Expected Results

Get the object with no crash

Actual Results

Crash! Error message is *** error for object 0x170230ea4: Invalid pointer dequeued from free list. Stacktrace:

Crashed: com.apple.main-thread
0  libsystem_kernel.dylib         0x180fd5014 __pthread_kill + 8
1  libsystem_pthread.dylib        0x18109f334 pthread_kill + 112
2  libsystem_c.dylib              0x180f499c4 abort + 140
3  libsystem_malloc.dylib         0x18101a9e8 nanozone_default_reader + 330
4  libsystem_malloc.dylib         0x18101bc54 _nano_malloc_check_clear + 412
5  libsystem_malloc.dylib         0x18101ac38 nano_malloc + 44
6  libsystem_malloc.dylib         0x181009664 malloc_zone_malloc + 172
7  libsystem_malloc.dylib         0x18100c56c malloc + 32
8  libc++abi.dylib                0x180a2b6b0 operator new(unsigned long) + 48
9  Realm                          0x10194f11c void std::__1::vector<realm::QueryGroup, std::__1::allocator<realm::QueryGroup> >::__emplace_back_slow_path<>() + 148
10 Realm                          0x10193c15c realm::Query::Query() + 44
11 Realm                          0x1017377e4 realm::TableViewBase::TableViewBase() (optional.hpp:672)
12 Realm                          0x1017338f4 realm::Results::Results(std::__1::shared_ptr<realm::Realm>, realm::Table&) (table_view.hpp:450)
13 Realm                          0x10175a0a4 RLMGetObjects (RLMObjectStore.mm:480)
14 RealmSwift                     0x101d6fb78 Realm.objects<A where ...> (A.Type) -> Results<A> (Realm.swift:457)
15 KidFund                        0x1001950cc currentUser.getter (UserDataService.swift)
... more stuff, let me know if this is needed

Steps to Reproduce

Not sure. This has happened only once, so this is the only stack trace I have.

The app is attempting to start up and check whether there is a user already logged in (by seeing if currentUser != nil). currentUser is a User which is a Realm object. In this instance, the tester reported that they logged out, which crashed the app, and that the app always crashed when trying to reopen. The crash loop was fixed by reinstalling.

Version of Realm and Tooling

ProductName:    Mac OS X
ProductVersion: 10.12.4
BuildVersion:   16E195

/Applications/Xcode.app/Contents/Developer
Xcode 8.3.2
Build version 8E2002

/Users/michael/.rvm/gems/ruby-2.3.1/bin/pod
1.2.0
Realm (2.7.0)
RealmSwift (2.7.0)
RealmSwift (~> 2.0)

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

carthage not found
(not in use here)

git: aliased to hub
git version 2.4.3
hub version 2.2.1

[timbroder]

Some additional info on this crash (Which we didn't find until we built for an app store submission)

This crash does not happen if we add "-Onone" to Other Swift Flags to our Release scheme in our project settings

[bdash]

This crash indicates that malloc's data structures contain bogus information. While the crashing backtrace is inside Realm, this only indicates the point at which malloc detected the corrupted data was when Realm attempted an allocation. Some code that was executed prior to this point, perhaps within Realm but just as likely within your app or some other library, is what actually corrupted the data. Guard Malloc, and the other malloc debugging features described that page, can be good tools for tracking down corruption like this.

[mrh-is]

Ah, ok, thanks for the info! I'll test using that page and report back with my findings (for posterity).

[tungvoduc]

I also experience this type of crash a lot in my app, only after realm.deleteAll() has been called when user logs out from the app.

[mrh-is]

Hey @bdash, I've got this is a reproducible test project!

The crash can be prevented really simply in (at least) two ways:

1. print anything other than a literal in ModelDataService.count(in:)
2. Force cast realm in ModelDataService.count(in:) to a Realm (i.e., return (realm as! Realm).objects(Model.self).count)

As a note, this only crashes when compiled for release, not for debugging.

The issue seems to be that ModelDataService.count(in:) is being called twice very fast, and maybe the protocol has something to do with it? I've reached the end of what I know really. Hopefully this reveals the issue!

EDIT: It seems like the project doesn't crash on a fresh install. (If you see printed stuff in the console, you haven't crashed.) I was able to get it to crash by just running the app a few times in the simulator. Seems to be about 50% of the launches crash. Very interesting.

[bdash]

Thanks for creating that reproducible case, @mrh-is! A quick look shows that the problem is 100% reproducible if I enable Malloc Scribble or Guard Malloc in the scheme. My initial guess is that this may be a Swift compiler bug due to the fact that even trivial changes to the source end up hiding the crash.

[bdash]

The underlying problem appears to be that the single RealmSwift.Realm instance that is allocated has been deallocated prior to the call to realm.objects(Model.self).count within ModelDataService.count(in:). Since the RealmSwift.Realm instance is a Swift object its lifetime is managed automagically by the Swift compiler and runtime, and so a premature deallocation is very likely to be due to a Swift compiler or runtime bug. At this point I think you'd need to file a bug report against Swift.

[mrh-is]

Done, thanks for the debugging help!

And for anyone else that happens to find this bug, I fixed it with a force cast, and that seems to be holding up.

[jpsim]

Thanks for filing that Swift bug, @mrh-is !