Allow error handling when realm is accessed with the wrong encryption key

[issue2k]

Currently the realmWithPath method indicates that there is some error handling possible. I would expect that when accessing a realm with wrong encryption key, it just gives an error. Instead its throwing an exception which causes a crash of the app. As i am not able to handle C++ exceptions on 32bit devices (And i want to avoid handling the control flow by catching exceptions) it would be helpful if realm would not throw an exception and give a useful error message and a uniqe code to be able to handle it.

This is what i am trying to do:

[RLMRealm realmWithPath:RLMRealm.defaultRealmPath encryptionKey:key readOnly:NO error:&error]

on 64bit devices i am able to handle the thrown C++ exceptions. On 32bit devices there seems to be no way:

libc++abi.dylib: terminating with uncaught exception of type tightdb::util::DecryptionFailed: Decryption failed

Any change or other idea how i could handle this case without crashing on 32 bit devices?

[segiddins]

@issue2k I've looked through the relevant Realm code paths, and I'm not quite sure how you'd ever be getting that C++ exception. Additionally, there shouldn't be any difference handling exceptions between 32 and 64-bit devices, so something strange is going on. Would it be possible to share a bit more context around the failure? A project that reproduces it would be preferable, but even a complete stack trace would be a great help. As always, if you want to keep things private, you can send them to help@realm.io. Thanks!

[issue2k]

@segiddins thanks for your reply.

https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Exceptions/Articles/Exceptions64Bit.html

I expect that i run into that:

On the other hand, an Objective-C catch clause taking a dynamically typed exception object (@catch(id exception)) can catch any Objective-C exception, but cannot catch any C++ exceptions. So, for interoperability, use @catch(...) to catch every exception and @throw; to rethrow caught exceptions. In 32-bit, @catch(...) has the same effect as @catch(id exception).

If i understand the last sentence correctly its not possible to handle C++ exceptions in Objective-C on 32bit platforms.

https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Exceptions/Articles/Exceptions64Bit.html

After posting the issue i realized that the problem only occurs on Simulators < iPhone 5s. I will send an example project to you.

[segiddins]

@issue2k an example project would be incredibly helpful, as you shouldn't be getting any C++ exceptions from the core library -- those should be caught by realm, and then, if necessary, mapped to ObjC exceptions.

[issue2k]

@segiddins it took me a while to reproduce this inside of an example project. It only happens under very special conditions. What i can say now is that the crash only happens when i have included the pod CrashlyticsFramework, without Crashlytics everything is fine. It even only crashes on Simulator <= iPhone 5. It does NOT crash on a real device <= iPhone 5 (tested with iPhone 4s only).

Find my example project here: https://github.com/issue2k/realm-encryption-test

To reproduce the issue do the following:

1. Start Project on Simulator <= iPhone 5
2. Stop
3. Start Project again on the same Simulator.

[segiddins]

@issue2k thanks so much for digging into this! I'll be sure to take a look at that example project, and see if there's anything we can do to improve that experience in the simulator.

[segiddins]

@issue2k I just cloned that project and ran it in both the iPhone 4S and iPhone 5 iOS 8.2 simulators, and did not see any crash.

[issue2k]

@segiddins I am using 8.3, will check 8.2 as soon as possible

[issue2k]

I can confirm that this only happens on iOS 8.3 Simulators <= iPhone 5. Validated this on 8.2 and 8.3 with two different computers now.

#8 0x000cb680 in realm::util::AESCryptor::try_read(int, long long, char*, unsigned long) ()
#9 0x000cbd87 in realm::util::EncryptedFileMapping::set(void*, unsigned long) ()
#10   0x000cbb3b in realm::util::EncryptedFileMapping::EncryptedFileMapping(realm::util::SharedFileInfo&, void*, unsigned long, realm::util::File::AccessMode) ()
#11   0x000cf772 in realm::util::mmap(int, unsigned long, realm::util::File::AccessMode, char const*) ()
#12   0x000ce1f9 in realm::util::File::map(realm::util::File::AccessMode, unsigned long, int) const ()
#13   0x000d3496 in realm::SlabAlloc::attach_file(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool, bool, bool, bool, char const*, bool) ()
#14   0x0017a1fc in realm::SharedGroup::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool, realm::SharedGroup::DurabilityLevel, bool, char const*) ()
#15   0x0017c4cd in realm::SharedGroup::open(realm::Replication&, realm::SharedGroup::DurabilityLevel, char const*) ()
#16   0x000afa96 in realm::SharedGroup::SharedGroup(realm::Replication&, realm::SharedGroup::DurabilityLevel, char const*) at /Users/jakob/playground/realm-encryption-test/Pods/Headers/Private/Realm/realm/group_shared.hpp:619
#17   0x000af87f in realm::SharedGroup::SharedGroup(realm::Replication&, realm::SharedGroup::DurabilityLevel, char const*) at /Users/jakob/playground/realm-encryption-test/Pods/Headers/Private/Realm/realm/group_shared.hpp:620
#18   0x000a6399 in std::__1::__unique_if<realm::SharedGroup>::__unique_single std::__1::make_unique<realm::SharedGroup, realm::Replication&, realm::SharedGroup::DurabilityLevel&, char const*>(realm::Replication&&&, realm::SharedGroup::DurabilityLevel&&&, char const*&&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:3047
#19   0x000a6335 in -[RLMRealm initWithPath:key:readOnly:inMemory:dynamic:error:] at /Users/jakob/playground/realm-encryption-test/Pods/Realm/Realm/RLMRealm.mm:182
#20   0x000a8445 in +[RLMRealm realmWithPath:key:readOnly:inMemory:dynamic:schema:error:] at /Users/jakob/playground/realm-encryption-test/Pods/Realm/Realm/RLMRealm.mm:353
#21   0x000a7965 in +[RLMRealm realmWithPath:encryptionKey:readOnly:error:] at /Users/jakob/playground/realm-encryption-test/Pods/Realm/Realm/RLMRealm.mm:304
#22   0x000310f2 in -[LabelViewController loadView] at /Users/jakob/playground/realm-encryption-test/Encryption/LabelViewController.m:27
#23   0x00ca9aef in -[UIViewController loadViewIfRequired] ()
#24   0x00caa095 in -[UIViewController view] ()
#25   0x00b9be85 in -[UIWindow addRootViewControllerViewIfPossible] ()
#26   0x00b9c34c in -[UIWindow _setHidden:forced:] ()
#27   0x00b9c648 in -[UIWindow _orderFrontWithoutMakingKey] ()
#28   0x00baa9b6 in -[UIWindow makeKeyAndVisible] ()
#29   0x00030d95 in -[AppDelegate application:didFinishLaunchingWithOptions:] at /Users/jakob/playground/realm-encryption-test/Encryption/AppDelegate.m:10
#30   0x00b3efd7 in -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] ()
#31   0x00b3fdc1 in -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] ()
#32   0x00b43422 in -[UIApplication _runWithMainScene:transitionContext:completion:] ()
#33   0x00b5c93e in __84-[UIApplication _handleApplicationActivationWithScene:transitionContext:completion:]_block_invoke ()
#34   0x00b4204a in -[UIApplication workspaceDidEndTransaction:] ()
#35   0x0438fc9e in __37-[FBSWorkspace clientEndTransaction:]_block_invoke_2 ()
#36   0x0438f72f in __40-[FBSWorkspace _performDelegateCallOut:]_block_invoke ()
#37   0x043a1d7c in __31-[FBSSerialQueue performAsync:]_block_invoke_2 ()
#38   0x01fbb050 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ ()
#39   0x01fb0963 in __CFRunLoopDoBlocks ()
#40   0x01fb00c8 in __CFRunLoopRun ()
#41   0x01fafa5b in CFRunLoopRunSpecific ()
#42   0x01faf88b in CFRunLoopRunInMode ()
#43   0x00b41a02 in -[UIApplication _run] ()
#44   0x00b45106 in UIApplicationMain ()
#45   0x0003194a in main at /Users/jakob/playground/realm-encryption-test/Encryption/main.m:26
#46   0x0259eac9 in start ()

[tgoyne]

See http://stackoverflow.com/questions/21150223/ld-warning-too-many-personality-routines-for-compact-unwind-to-encode and https://devforums.apple.com/thread/267548?tstart=0. It looks like no one has found a workaround, but I'm going to try to rebuilding everything with xcode 6.3 to see if that helps (the current core release was built with an older version of clang).

[tgoyne]

Rebuilding core with Xcode 6.3 doesn't eliminate the warning, so I don't think there's anything we can do.

[jpsim]

Closing as this is a limitation inherent to iOS and cannot be avoided outright. Please see @tgoyne's previous links for potential workarounds.