Set error if mmap address space is exhausted

[mrackwitz]

This is based on the assumption that the address space will be exhausted most commonly either on trying to map a Realm database which doesn't fit in the left address space or on committing a writing transaction when the memory is resized, while this could also happen on (auto-)refreshes.
Fixes #2269.

/c @jpsim @bdash @tgoyne

[jpsim]

Return a recoverable RLMErrorAddressSpaceExhausted error rather than crashing when failing to mmap in Realm initialization or write commit.

[jpsim]

Some context from a previous conversation: although this exception can be thrown in advance_read, it's not easily recoverable there because all accessors will become invalid. Also, advance_read can happen implicitly in so many situations that it would be impractical to allow error handling there.

One solution to this might be to allow users to register custom error handlers that we would invoke for them, but the recovery options would still be very limited, so probably not worthwhile implementing unless there's a strong demand for it.

I'll wait for the compile issues to be sorted out before doing a full review.

[mrackwitz]

This passes now on CI. (Jenkins failure is due to the device build being aborted.)

[tgoyne]

It'd be nice to have a test that verifies that we actually get the correct error and that it's recoverable. An idea for how to do this is:

create realm file with a 1MB string, close realm
size = 1024 * 1024 * 1024
while (size >= 1024 * 1024) {
    kern_return_t ret = vm_allocate(size)
    if (ret == KERN_NO_SPACE)
        size /= 2
    else
        add allocation to list to free
}
try to open realm, assert that expected error is given
deallocate all allocations above
try again to open realm and verify that it works

This would obviously need to be 32-bit only. It may turn out to be unreasonably slow to run it as part of the normal test suite, but it'd still be good to at least do a one-time verification.

[mrackwitz]

@tgoyne: Thanks for the very detailed proposal how to test that. I was thinking about that and @ironage was also giving me some good feedback. I'll report back, once I was able to reproduce it, whether it is actually recoverable and if it's a good idea to test that continuously.

[jpsim]

👍 if testing confirms this works

[mrackwitz]

I think, I could reproduce it, assuming that my test case makes sense. 🙈
It didn't seemed like it was a huge performance regression for the test suite at least locally for me, but it might look different for our CI VMs.

[mrackwitz]

I think it would be good if someone could review my test case and give a 👍 if everything is alright.

[bdash]

This typedef shouldn't be necessary since this code is in an Objective-C++ file.

[bdash]

👍

[jpsim]

👍