realm/realm-core

Core database component for the Realm Mobile Database SDKs

Realm is a mobile database that runs directly inside phones, tablets or wearables - check out realm.io.

This repository holds the source code for the core database component used by all the Realm Mobile Database products:

• Realm C++
• Realm Dart/Flutter
• Realm Java
• Realm Kotlin
• Realm Swift/Objective-C
• Realm .NET
• Realm Node.js/React Native/Web

Realm Core is not in itself an "end-user" product with a publicly stable and supported API.

Refer to the Atlas Device SDK documentation for information about Realm and using the SDKs.

Building Realm

How to build Realm Core is described here.

Contributing

See CONTRIBUTING.md for more details!

Code of Conduct

This project adheres to the MongoDB Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].

License

Realm Core is published under the Apache 2.0 license.

See the THIRD-PARTY-NOTICES file for licenses related to included third party libraries.

Feedback

Feedback to the Realm SDK's should be given in the respective SDK's github mentioned in the top of this readme. For anything specifically about Realm Core, please create an issue here.

realm-core's Issues

Memory leak in Query

We have a bunch of memory leaks in the query interface:

N Address Category Timestamp Live Size Responsible Library Responsible Caller
0 0x10520a480 Malloc 64 Bytes 00:01.492.198 • 64 tightdb_unit_tests tightdb::Query::Equal(unsigned long, long long)
1 0x10520a300 Malloc 64 Bytes 00:01.492.089 • 64 tightdb_unit_tests tightdb::Query::Equal(unsigned long, long long)
2 0x10520c3d0 Malloc 64 Bytes 00:01.221.287 • 64 tightdb_unit_tests tightdb::Query::Less(unsigned long, long long)
3 0x10520c3a0 Malloc 48 Bytes 00:01.221.287 • 48 tightdb_unit_tests tightdb::Query::Or()
4 0x10520bc80 Malloc 64 Bytes 00:01.221.286 • 64 tightdb_unit_tests tightdb::Query::Greater(unsigned long, long long)
5 0x10520bb50 Malloc 64 Bytes 00:01.221.148 • 64 tightdb_unit_tests tightdb::Query::Less(unsigned long, long long)
6 0x10520bb10 Malloc 64 Bytes 00:01.221.146 • 64 tightdb_unit_tests tightdb::Query::Less(unsigned long, long long)
7 0x10520bae0 Malloc 48 Bytes 00:01.221.144 • 48 tightdb_unit_tests tightdb::Query::Or()
8 0x10520baa0 Malloc 64 Bytes 00:01.221.143 • 64 tightdb_unit_tests tightdb::Query::Greater(unsigned long, long long)
9 0x10520b9e0 Malloc 64 Bytes 00:01.220.978 • 64 tightdb_unit_tests tightdb::Query::Less(unsigned long, long long)
10 0x10520b9b0 Malloc 48 Bytes 00:01.220.978 • 48 tightdb_unit_tests tightdb::Query::Or()
11 0x10520c2e0 Malloc 64 Bytes 00:01.220.976 • 64 tightdb_unit_tests tightdb::Query::Greater(unsigned long, long long)
12 0x10520b8f0 Malloc 64 Bytes 00:01.220.846 • 64 tightdb_unit_tests tightdb::Query::Less(unsigned long, long long)

Update master branch. Ensure continous update.

Valgrind report use of uninitialized memory in testarray.cpp::hasZeroByte

Valgrind report use of uninitialized memory in testarray.cpp::hasZeroByte

It is triggered in the unit test FindhasZeroByte at line 705, and in some of the following calls:

Alexanders-MacBook-Air:Debug alexanderstigsen$ valgrind --track-origins=yes ./tightdb_unit_tests 
==88587== Memcheck, a memory error detector
==88587== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==88587== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==88587== Command: ./tightdb_unit_tests
==88587== 
==88587== Conditional jump or move depends on uninitialised value(s)
==88587==    at 0x1000DCE09: Array::FindNaive(long long, unsigned long, unsigned long) const (Array.cpp:608)
==88587==    by 0x1000DCBEC: Array::Find(long long, unsigned long, unsigned long) const (Array.cpp:535)
==88587==    by 0x100019431: hasZeroByte(long long, unsigned long) (testarray.cpp:687)
==88587==    by 0x100019895: TestFindhasZeroByte::RunImpl() const (testarray.cpp:705)
==88587==    by 0x1000D542D: void UnitTest::ExecuteTest<UnitTest::Test>(UnitTest::Test&, UnitTest::TestDetails const&) (ExecuteTest.h:25)
==88587==    by 0x1000D4E7B: UnitTest::Test::Run() (Test.cpp:34)
==88587==    by 0x1000D6016: UnitTest::TestRunner::RunTest(UnitTest::TestResults*, UnitTest::Test*, int) const (TestRunner.cpp:61)
==88587==    by 0x1000D69B7: int UnitTest::TestRunner::RunTestsIf<UnitTest::True>(UnitTest::TestList const&, char const*, UnitTest::True const&, int) const (TestRunner.h:40)
==88587==    by 0x1000D5EC8: UnitTest::RunAllTests() (TestRunner.cpp:17)
==88587==    by 0x100084263: main (main.cpp:4)
==88587==  Uninitialised value was created by a heap allocation
==88587==    at 0xD6D9: malloc (vg_replace_malloc.c:266)
==88587==    by 0x1000D9CC7: Allocator::Alloc(unsigned long) (alloc.h:21)
==88587==    by 0x1000DA34E: Array::Alloc(unsigned long, unsigned long) (Array.cpp:1191)
==88587==    by 0x1000DA192: Array::Array(ColumnDef, Array*, unsigned long, Allocator&) (Array.cpp:27)
==88587==    by 0x1000DA0B2: Array::Array(ColumnDef, Array*, unsigned long, Allocator&) (Array.cpp:23)
==88587==    by 0x100019352: hasZeroByte(long long, unsigned long) (Array.h:69)
==88587==    by 0x100019895: TestFindhasZeroByte::RunImpl() const (testarray.cpp:705)
==88587==    by 0x1000D542D: void UnitTest::ExecuteTest<UnitTest::Test>(UnitTest::Test&, UnitTest::TestDetails const&) (ExecuteTest.h:25)
==88587==    by 0x1000D4E7B: UnitTest::Test::Run() (Test.cpp:34)
==88587==    by 0x1000D6016: UnitTest::TestRunner::RunTest(UnitTest::TestResults*, UnitTest::Test*, int) const (TestRunner.cpp:61)
==88587==    by 0x1000D69B7: int UnitTest::TestRunner::RunTestsIf<UnitTest::True>(UnitTest::TestList const&, char const*, UnitTest::True const&, int) const (TestRunner.h:40)
==88587==    by 0x1000D5EC8: UnitTest::RunAllTests() (TestRunner.cpp:17)
==88587== 

Table::find() returns size_t(-1) on 'not found'

The C++ reference documentation states that Table::find() returns 'null' on 'not found'. It returns size_t(-1).

use of ssize_t causes compile error in VS2010

win32/types.h contains :
typedef ptrdiff_t ssize_t;

this causes compile errors in VS2010.

The use of ssize_t can be questioned. some of the places it might be better to change API's.
discussion needed.

Remove std::size_t from all header files.

Use:
using std::size_t
using std::time_t

Corrupted Realm File

Info:
https://app.asana.com/0/1462112455450/28844321666679

Segmentation fault in php interface when opening a file that doesn't exists

Example:

$group_file = new Group("file", "does_not_exist");

Index, broken performance

If the value range of integers is large, performance drops towards 0. Reproduce: In test-tightdb, modify % 1000 to % 10000 or more, in these two places:

    // create random string
    const size_t n = rand() % 1000;// * 10 + rand();
    const string s = number_name(n);

(insertion) and

    for (size_t i = 0; i < 100000; ++i) {
        const size_t n = rand() % 1000;
        const size_t res = table.first.Find(n);

(search)

Bug in Table.h: Mixed(ColumnType v)

In Table.h:
class Mixed {
public:
explicit Mixed(ColumnType v) {assert(v = COLUMN_TYPE_TABLE); m_type = COLUMN_TYPE_TABLE;}

is missing a "=" after "v =" to assert correctly.

Better yet would be to prevent this run-time error at compile time with something like:
class ColumnTypeTable {};
class Mixed {
public:
Mixed(ColumnTypeTable) { ... }
}
Use:
Mixed m(ColumnTypeTable());

Misc. cleanup tasks

Eliminate Array::Preset() or merge with Array::ensure_minimum_width().

Probably replace Array::ensure_minimum_width() with Array::ensure_capacity() which should also accept a minimum number of elements.

Additional unit tests for strings with NUL-bytes in test_index_string.cpp

https://app.asana.com/0/1462112455450/29026506375522

Implement Mixed::GetTable

basic_table.hpp: fix the "FIXME" items.

../tightdb/impl/transact_log.hpp:741: [realm-core-0.88.5] Assertion failed: _impl::TableFriend::is_link_type(ColumnType(type))

Originally reported by: @segiddins

From realm/realm-swift#1662:

../tightdb/impl/transact_log.hpp:741: [realm-core-0.88.5] Assertion failed: _impl::TableFriend::is_link_type(ColumnType(type))
0   MyApp                            0x006d72ad _ZN7tightdb4util9terminateEPKcS2_lbxx + 580
1   MyApp                            0x0075702f _ZN7tightdb5_impl17TransactLogParser8do_parseINS_5Group16TransactReverserEEEvRT_ + 4982
2   MyApp                            0x007557b7 _ZN7tightdb5Group16reverse_transactEmRKNS_10BinaryDataE + 182
3   MyApp                            0x0075da0f _ZN7tightdb11SharedGroup32do_rollback_and_continue_as_readEPKcS2_ + 22
4   MyApp                            0x0075286d _ZN7tightdb5_impl17WriteLogCollector26do_rollback_write_transactERNS_11SharedGroupE + 92
5   MyApp                            0x0075d987 _ZN7tightdb11SharedGroup29rollback_and_continue_as_readEv + 98
6   MyApp                            0x0065abe7 _ZN7tightdb14LangBindHelper29rollback_and_continue_as_readERNS_11SharedGroupE + 14
7   MyApp                            0x00656c3f -[RLMRealm cancelWriteTransaction] + 206
8   MyApp                            0x00618695 RLMUpdateRealmToSchemaVersion + 624
9   MyApp                            0x006546c9 +[RLMRealm realmWithPath🔑readOnly:inMemory:dynamic:schema:error:] + 2988
10  MyApp                            0x00653721 +[RLMRealm realmWithPath:readOnly:error:] + 192
11  MyApp                            0x006535c9 +[RLMRealm realmWithPath:] + 152
12  MyApp                            0x0016c65b -[DSAppDelegate application:didFinishLaunchingWithOptions:] + 8434
13  UIKit                               0x316095a7 <redacted> + 274
14  UIKit                               0x31608efb <redacted> + 1610
15  UIKit                               0x3160358b <redacted> + 714
16  UIKit                               0x3159f709 <redacted> + 3540
17  UIKit                               0x3159e871 <redacted> + 72
18  UIKit                               0x31602cc9 <redacted> + 616
19  GraphicsServices                    0x33bd4aed <redacted> + 608
20  GraphicsServices                    0x33bd46d7 <redacted> + 34
21  CoreFoundation                      0x2ed48ab7 <redacted> + 34
22  CoreFoundation                      0x2ed48a53 <redacted> + 346
23  CoreFoundation                      0x2ed47227 <redacted> + 1398
24  CoreFoundation                      0x2ecb1f0f CFRunLoopRunSpecific + 522
25  CoreFoundation                      0x2ecb1cf3 CFRunLoopRunInMode + 106
26  UIKit                               0x31601ef1 <redacted> + 760
27  UIKit                               0x315fd16d UIApplicationMain + 1136
28  MyApp                            0x0018de25 main + 116
29  libdyld.dylib                       0x399d5ab7 <redacted> + 2
IMPORTANT: if you see this error, please send this log to [email protected].

Implement Mixed subtable methods

For C++ highlevel:
A Mixed column with cells being subtables, poses some challenge. So for this we could make the following API:

// Create a subtable of the type T at the specific cell
createSubtable()

// Get the subtable of type T at the specific cell
getSubtable() (return NULL if not compatible with type T)

// Return true if the cell is of type T
bool isSubtable() (helper for above)

// Schema not defined at compile time, dynamic during runtime:
"DynamicSchemaTable" getSubtable()
+ methods for looking at the spec and updating it

Column.FindAll() appends to result column instead of clearing it initially

Is this correct behaviour?

Simpler C++ interface to adding subtables with Spec()

It should be possible to make the Spec() interface simpler and more intuitive.
Go think...

test issue

test

Update TableView methods

Support:

• Clear()
• PopBack()
• GetSet{Binary, Mixed, Table)
• ClearTable()

Align method naming with Table:
DeleteRow

Should Table also have Sum, Max, Min?

Append Arrays

Possibility to append arrays would be handy. Such as

Array a;
Array b;
...
Array c = a + b;

throw exception rather than asserting when detecting a corrupted realm

Originally reported by: @alazier

https://app.asana.com/0/1462112455450/29982665261831

When opening a Realm, any errors should be exceptions so they can be caught and returned as an NSError to users of the binding. Ideally users would be able to delete their Realm files in such instances and start a new db. This functionality has been requested by users.

Replication

In encode_int():

TIGHTDB_STATIC_ASSERT(std::numeric_limits<T>::is_integer, "Integer required");

If insertion can fail in replication, then insertion must fail in "core" insertion too, because behaviour in "core" and replication should be completely identical.

TEST(Table_FindAll_Int) fails in assert()

Assert fails lots of places in this test, in 64-bit debug mode in VC

group_writer.cpp:30: [realm-core-0.88.4] Assertion failed: fpositions.size()==flengths.size()

Originally reported by: @segiddins

From https://secure.helpscout.net/conversation/77016921/656/

group_writer.cpp:30: [realm-core-0.88.4] Assertion failed: fpositions.size()==flengths.size() [524288, 0]
0 Medlemskort 0x00000001007d0a7c _ZN7tightdb4util9terminateEPKcS2_lbxx + 684
1 Medlemskort 0x0000000100893f6a _ZN7tightdb11GroupWriter11write_groupEv + 1898
2 Medlemskort 0x0000000100892f66 _ZN7tightdb11SharedGroup16low_level_commitEy + 310
3 Medlemskort 0x0000000100892c88 _ZN7tightdb11SharedGroup9do_commitEv + 120
4 Medlemskort 0x0000000100892d32 _ZN7tightdb11SharedGroup27commit_and_continue_as_readEv + 18
5 Medlemskort 0x0000000100731185 -[RLMRealm commitWriteTransaction] + 122
6 Medlemskort 0x00000001005863e0 -[PersistenceManager updateOffersDistance] + 540
7 Foundation 0x0000000101da12df __NSThread__main__ + 1167
8 libsystem_pthread.dylib 0x000000010531c268 _pthread_body + 131
9 libsystem_pthread.dylib 0x000000010531c1e5 _pthread_body + 0
10 libsystem_pthread.dylib 0x000000010531a41d thread_start + 13
IMPORTANT: if you see this error, please send this log to [email protected].

C++ Interface renaming

Consider changing naming of all C++ methods:

1. Closer to c++ vector and lowercase
2. Specific:
   * LeftParan() -> group(), RightParan() -> endgroup()
   * GetSize() -> size()
   * Get(i) -> at(i)
   * IsEmpty() -> empty()
   * Binary -> Blob

mem leak

me@ubuntu:/mnt/hgfs/D/tightdb_lasse/test/test-tightdb$ valgrind --leak-check=full ./test-tightdb
==26714== Memcheck, a memory error detector
==26714== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==26714== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==26714== Command: ./test-tightdb
==26714==
Memory usage: 99860480 bytes
Search (small integer): 32ms
Search (byte-size integer): 24ms
errorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorerrorSearch (string): 169ms
Add index: 391ms
Memory usage2: 100028416 bytes
Search index: 8479ms
==26714==
==26714== HEAP SUMMARY:
==26714== in use at exit: 384 bytes in 1 blocks
==26714== total heap usage: 164,649 allocs, 164,648 frees, 20,650,058 bytes allocated
==26714==
==26714== 384 bytes in 1 blocks are definitely lost in loss record 1 of 1
==26714== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261)
==26714== by 0x411EE1: AdaptiveStringColumn::LeafInsert(unsigned long, char const_) (ColumnString.cpp:202)
==26714== by 0x413341: ColumnBase::NodeChange ColumnBase::DoInsert<char const_, AdaptiveStringColumn>(unsigned long, char const_) (Column_tpl.h:192)
==26714== by 0x4124FB: bool ColumnBase::TreeInsert<char const_, AdaptiveStringColumn>(unsigned long, char const_) (Column_tpl.h:82)
==26714== by 0x411B3D: AdaptiveStringColumn::Insert(unsigned long, char const_) (ColumnString.cpp:132)
==26714== by 0x41BDCC: Table::InsertString(unsigned long, unsigned long, char const_) (Table.cpp:342)
==26714== by 0x41D9DD: TestTable::Add(long, char const_, long, TypeEnum) (test-tightdb.cpp:37)
==26714== by 0x41D393: main (test-tightdb.cpp:49)
==26714==
==26714== LEAK SUMMARY:
==26714== definitely lost: 384 bytes in 1 blocks
==26714== indirectly lost: 0 bytes in 0 blocks
==26714== possibly lost: 0 bytes in 0 blocks
==26714== still reachable: 0 bytes in 0 blocks
==26714== suppressed: 0 bytes in 0 blocks
==26714==
==26714== For counts of detected and suppressed errors, rerun with: -v
==26714== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
me@ubuntu:/mnt/hgfs/D/tightdb_lasse/test/test-tightdb$

FindAll

Find a place for Clear() on destination result before FindAll (Table maybe?)

table.cpp:1902: [realm-core-0.88.4] Assertion failed: is_attached()

Originally reported by: @yoshyosh

https://app.asana.com/0/1462112455450/28820265242103

Assorted stack traces from Target crashes

Originally reported by: @jpsim

https://app.asana.com/0/1462112455450/29783740157678

Memory leak by TopLevelTable::GetTableSize() + assert crash

The code at the end of this issue crashes during exit of main(), in:

SlabAlloc::~SlabAlloc() {

ifdef _DEBUG

if (!IsAllFree()) {
    m_slabs.Print();
    m_freeSpace.Print();
    assert(false);
}

because IsAllFree() returns false. Happens in VS and gcc/Linux for the commit https://github.com/rrrlasse/tightdb/commit/4d3ebb50760bcb7b36b39ac369aac0f47359ed0f

include "UnitTest++.h"

include

include <math.h>

include "Column.h"

include

include "tightdb.h"

include "Group.h"

int main() {
Group group;
TopLevelTable& table = group.GetTable("test");

Spec s = table.GetSpec();
s.AddColumn(COLUMN_TYPE_INT,    "i");
Spec sub = s.AddColumnTable(    "tab");
    sub.AddColumn(COLUMN_TYPE_BOOL,   "active");
    sub.AddColumn(COLUMN_TYPE_INT,    "count");
    sub.AddColumn(COLUMN_TYPE_STRING, "str");
table.UpdateFromSpec(s.GetRef());

// Add a row of data
table.InsertInt(0, 0, 6);
table.InsertTable(1, 0);
table.InsertDone();

Table subtable = table.GetTable(1,0);
subtable.InsertBool   (0, 0, true);
subtable.InsertInt    (1, 0, 6);
subtable.InsertString (2, 0, "Fido");
subtable.InsertDone();

std::cerr << table.GetTableSize(1,0) << std::endl;

// const int res = UnitTest::RunAllTests();

ifdef _MSC_VER

// getchar(); // wait for key

endif

//return res;
return 0;

}

Readlock version confusion

It looks like the author (Alexander) was confused about whether to pass the "read lock version" as an argument to Group::zero_free_space() or store it in the Group instance:

https://github.com/Tightdb/tightdb/blob/master/src/tightdb/group.cpp#L691

It is already pretty hard to figure out what is going on without this obscurity, so I would love to see it resolved soon.

By the way, I think a semi-thorough explanation of the version mechanics in one of the involved source files would be appropriate.

Testcases: Verify all methods has sufficient testcoverage

Organize files for distribution: /include, /lib...

and reduce number of needed include files.

Add "tightdb header" in all files

New feature: Add [] accessor functionality from C++ in TableView

link_view.cpp:37: [realm-core-0.88.4] Assertion failed: !m_row_indexes.is_attached() || link_ndx <= m_row_indexes.size()

Originally reported by: @yoshyosh

https://app.asana.com/0/1462112455450/28820265242108

Handover of Rows and TableViews between threads

https://app.asana.com/0/1462112455450/14526714198876

Error when database file exceeds 2GiB

Occasional error when the database file grows to beyond 2Gib.

The error has been seen when adding small lumps of data through many write transactions (1000-5000).

For unknown reasons, the database file often grows to these extreme sizes even with relatively little data inserted, but many transactions. In some cases, though, this does not happen, and the database file stays well below 100KiB for the exact same sequence and same number of inserts. This hints at another unrelated error.

The error almost always occurs at the 2GiB limit, but sometimes later. 3.1GiB has been observed.

The actual error varies, but this one is common:

group_writer.cpp:169: void tightdb::GroupWriter::WriteAt(std::size_t, const char*, std::size_t): Assertion `copy_end <= mmap_end' failed.

Table & TableView: Add average()

Non-normalized floats in replication

Since I don't know how to write comments in a non-pullrequested branch, I'm writing it here.

inline char* Replication::encode_float(char* ptr, float value)
{
TIGHTDB_STATIC_ASSERT(std::numeric_limits::is_iec559 &&

^ floats and doubles can be represented in non-ieee format if they are non-normalized, so remove this assert.

tightdb::Group::init_from_ref exception in encrypted Realm

Originally reported by: @jpsim

https://app.asana.com/0/1462112455450/29888466842420

Cleanup-idea

There are lots of initial index checks like "if (end == (size_t)-1) end = m_len;" and lots of optional start/end arguments. Find out what functions are exposed to user and delete these checks and optional arguments from all but those functions.

Add average() in Table and TableView

Table.InsertInteger() fails

In test-tightdb.cpp in the line:

    //  integers.InsertInt(0, p, (int64_t)rand2() % RANGE); 

This line doesn't increase row count. So the second time it executes with p = 1, it fails.

Database file growth rate varies extremely

When adding small lumps of data through many individual write transactions, the rate of growth of the database file is sometimes extremely high, and sometimes it is not.

With about 4000 transactions each one adding a single row to a simple two-column table, the database file generally grows to about 2GiB, which seems pretty excessive.

In some cases though, this does not happen, and the database file size remains at a few hundred KiB, and that is for the exact same sequence of transactions.

To me, this looks like an indication of a bug.

Query: Add Query for Mixed and BinaryEqual

string_data.hpp:202 [realm-core-0.88.5] Index out of bounds

https://app.asana.com/0/1462112455450/28850408700816

Memory leak when MAX_LIST_SIZE=5

export CL=/DMAX_LIST_SIZE=5
CL=/DMAX_LIST_SIZE=5
'/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/IDE/devenv.exe' /Rebuild 'Debug|x64' /project TightDB TightDB.sln
x64/Debug/TightDB.exe
Assertion failed: false, file src\alloc.cpp, line 37

Querying link view after move last over with an OR

Originally reported by: @segiddins

https://app.asana.com/0/1462112455450/30932475840791

Reported in realm/realm-swift#1725, Cocoa unit test demonstrating the issue at https://github.com/realm/realm-cocoa-private/tree/seg-move-last-over-or-query-bug (-[QueryTests testQueryAfterMoveLastOver])