Assertion failed: size_t(m_top.get(2) / 2)<=m_alloc.get_baseline()

[voidref]

Had my system freeze, and had to do a hard reset.

Submitting this here in case it helps in some way:

Attempting to open the realm for which I was last using causes this crash (reproducible)

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff8d7eb286 __pthread_kill + 10
1   libsystem_c.dylib               0x00007fff8f13cb53 abort + 129
2   io.Realm.Realm                  0x00000001091c5ee9 please_report_this_error_to_help_at_realm_dot_io + 9
3   io.Realm.Realm                  0x00000001091c62e8 tightdb::util::terminate(char const*, char const*, long, bool, long long, long long) + 936
4   io.Realm.Realm                  0x0000000109279e38 tightdb::Group::init_from_ref(unsigned long) + 696
5   io.Realm.Realm                  0x0000000109287286 tightdb::SharedGroup::begin_read(tightdb::SharedGroup::VersionID) + 182
6   io.Realm.Realm                  0x00000001091b228a -[RLMRealm getOrCreateGroup] + 65
7   io.Realm.Realm                  0x00000001091bcd56 RLMRealmSchemaVersion + 38
8   io.Realm.Realm                  0x00000001091b2b67 +[RLMRealm realmWithPath:key:readOnly:inMemory:dynamic:schema:error:] + 668
9   io.realm.Realm-Browser          0x00000001091409ef -[RLMRealmNode connect:] + 95
10  io.realm.Realm-Browser          0x000000010912abb8 __50-[RLMDocument initWithContentsOfURL:ofType:error:]_block_invoke + 72
11  libdispatch.dylib               0x00007fff9966ac13 _dispatch_client_callout + 8
12  libdispatch.dylib               0x00007fff9967804e _dispatch_barrier_sync_f_slow_invoke + 412
13  libdispatch.dylib               0x00007fff9966ac13 _dispatch_client_callout + 8
14  libdispatch.dylib               0x00007fff99676cbf _dispatch_main_queue_callback_4CF + 861
15  com.apple.CoreFoundation        0x00007fff91dcb939 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
16  com.apple.CoreFoundation        0x00007fff91d86d8f __CFRunLoopRun + 2159
17  com.apple.CoreFoundation        0x00007fff91d862d8 CFRunLoopRunSpecific + 296
18  com.apple.HIToolbox             0x00007fff8e80fa1f RunCurrentEventLoopInMode + 235
19  com.apple.HIToolbox             0x00007fff8e80f79a ReceiveNextEventCommon + 431
20  com.apple.HIToolbox             0x00007fff8e80f5db _BlockUntilNextEventMatchingListInModeWithFilter + 71
21  com.apple.AppKit                0x00007fff94026661 _DPSNextEvent + 964
22  com.apple.AppKit                0x00007fff94025c60 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 194
23  com.apple.AppKit                0x00007fff9401b973 -[NSApplication run] + 594
24  com.apple.AppKit                0x00007fff93f984a4 NSApplicationMain + 1832
25  libdyld.dylib                   0x00007fff9049e5c9 start + 1

[segiddins]

Hi @voidref, what version of the realm browser are you using? Additionally, could you please share the assertion failure that's accompanying the crash?

[voidref]

Realm Browser Version 0.90.6 (0.90.6)

I am not sure what you mean by 'share the assertion failure', but here's the metadata about the crash

Process:               Realm Browser [1201]
Path:                  /Users/USER/Downloads/*/Realm Browser.app/Contents/MacOS/Realm Browser
Identifier:            io.realm.Realm-Browser
Version:               0.90.6 (0.90.6)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Realm Browser [1201]
User ID:               501

Date/Time:             2015-03-09 11:51:30.484 -0700
OS Version:            Mac OS X 10.10.3 (14D87h)
Report Version:        11
Anonymous UUID:        3A1B990C-9708-A4F6-D51A-A17777E241C7

Sleep/Wake UUID:       D6D1C2BD-7BDE-4DBE-A5A9-6E8E53056E81

Time Awake Since Boot: 23000 seconds
Time Since Wake:       7100 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Application Specific Information:
abort() called

@segiddins Would you like a copy of the db?

[segiddins]

@voidref is there any chance that you have code that can reproduce the creation of the corrupted realm? If not, a copy of the realm file might prove helpful. Feel free to send any code or realm files confidentially to help@realm.io. Thanks!

[voidref]

@segiddins the realm creation is dead simple, and was working until my machine freaked out and forced a reboot.

I'm sending more detail to the email address attention to you, but I am sure this is the result of FS corruption, it's just that you may be able to recover from it ... maybe.

[voidref]

PS:

Ran the app in the sim, and got this output

group.cpp:136: [realm-core-0.88.4] Assertion failed: size_t(m_top.get(2) / 2)<=m_alloc.get_baseline() [12288, 8192]
0   The Journey                         0x0000000109f260ec _ZN7tightdb4util9terminateEPKcS2_lbxx + 684
1   The Journey                         0x0000000109fda018 _ZN7tightdb5Group13init_from_refEm + 696
2   The Journey                         0x0000000109fe7466 _ZN7tightdb11SharedGroup10begin_readENS0_9VersionIDE + 182
3   The Journey                         0x0000000109f11e3c -[RLMRealm getOrCreateGroup] + 65
4   The Journey                         0x0000000109f140ce -[RLMRealm beginWriteTransaction] + 109
5   The Journey                         0x0000000109eef0b7 RLMUpdateRealmToSchemaVersion + 99
6   The Journey                         0x0000000109f12735 +[RLMRealm realmWithPath:key:readOnly:inMemory:dynamic:schema:error:] + 1254
7   The Journey                         0x0000000109f1208e +[RLMRealm realmWithPath:readOnly:error:] + 51
8   The Journey                         0x0000000109f11ffa +[RLMRealm defaultRealm] + 69
9   The Journey                         0x0000000109ee953c +[RLMObject allObjects] + 38
10  The Journey                         0x0000000109eca413 _TFC11The_Journey26JourneyTableViewController11viewDidLoadfS0_FT_T_ + 787
11  The Journey                         0x0000000109eca8b2 _TToFC11The_Journey26JourneyTableViewController11viewDidLoadfS0_FT_T_ + 34
12  UIKit                               0x000000010b07eb60 -[UIViewController loadViewIfRequired] + 738
13  UIKit                               0x000000010b07ed5e -[UIViewController view] + 27
14  UIKit                               0x000000010b606dcc -[UIStoryboardEmbedSegue perform] + 314
15  UIKit                               0x000000010b07ea94 -[UIViewController loadViewIfRequired] + 534
16  UIKit                               0x000000010b07ed5e -[UIViewController view] + 27
17  UIKit                               0x000000010af9a5a9 -[UIWindow addRootViewControllerViewIfPossible] + 58
18  UIKit                               0x000000010af9a96f -[UIWindow _setHidden:forced:] + 247
19  UIKit                               0x000000010afa7229 -[UIWindow makeKeyAndVisible] + 42
20  UIKit                               0x000000010af4a677 -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 2732
21  UIKit                               0x000000010af4d38e -[UIApplication _runWithMainScene:transitionContext:completion:] + 1349
22  UIKit                               0x000000010af4c28c -[UIApplication workspaceDidEndTransaction:] + 179
23  FrontBoardServices                  0x00000001105f4f85 __31-[FBSSerialQueue performAsync:]_block_invoke_2 + 21
24  CoreFoundation                      0x000000010a36e49c __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
25  CoreFoundation                      0x000000010a3641e5 __CFRunLoopDoBlocks + 341
26  CoreFoundation                      0x000000010a363fa5 __CFRunLoopRun + 2389
27  CoreFoundation                      0x000000010a3633e6 CFRunLoopRunSpecific + 470
28  UIKit                               0x000000010af4bcf9 -[UIApplication _run] + 413
29  UIKit                               0x000000010af4eab0 UIApplicationMain + 1282
30  The Journey                         0x0000000109edc397 main + 135
31  libdyld.dylib                       0x000000010c99a145 start + 1
32  ???                                 0x0000000000000001 0x0 + 1
IMPORTANT: if you see this error, please send this log to help@realm.io.

[jpsim]

Thanks for all the info you posted here and in your email, @voidref! We're looking into what may have caused this and will update you as soon as we have something to report.

[juantrias]

Some of our users are experiencing a similar crash in the last version of our app. I do not have access to the device logs, only to the stacktrace on Crittercism. We only know that they had installed a previous version of our app with an old schema and Realm 0.88.0, in the last version we are using Realm 0.90.6. Maybe some data corrupted during the migration? Or trying to open the Realm before specifying a migration block? But in this case we should see a RLMException, isn't it?

This is the stacktrace:

SIGABRT

0   
libsystem_kernel.dylib 0x0000000194c7b270 __pthread_kill + 8
1   
libsystem_c.dylib 0x0000000194bf2b18 abort + 108
2   
MyCommsProNOVidyo 0x00000001004cc910 please_report_this_error_to_help_at_realm_dot_io + 8
3   
MyCommsProNOVidyo 0x00000001004ccc04 _ZN7tightdb4util9terminateEPKcS2_lbxx + 752
4   
MyCommsProNOVidyo 0x0000000100542dc8 _ZN7tightdb5Group13init_from_refEm + 624
5   
MyCommsProNOVidyo 0x000000010054cbc0 _ZN7tightdb11SharedGroup10begin_readENS0_9VersionIDE + 184
6   
MyCommsProNOVidyo 0x00000001004b9980 -[RLMRealm getOrCreateGroup] (RLMRealm.mm:347)
7   
MyCommsProNOVidyo 0x00000001004bbc7c -[RLMRealm beginWriteTransaction] (RLMRealm.mm:614)
8   
MyCommsProNOVidyo 0x0000000100498180 RLMUpdateRealmToSchemaVersion (RLMObjectStore.mm:238)
9   
MyCommsProNOVidyo 0x00000001004ba2a8 +[RLMRealm realmWithPath:key:readOnly:inMemory:dynamic:schema:error:] (RLMRealm.mm:512)
10  
MyCommsProNOVidyo 0x00000001004b9c38 +[RLMRealm realmWithPath:readOnly:error:] (RLMRealm.mm:408)
11  
MyCommsProNOVidyo 0x00000001004b9b98 +[RLMRealm defaultRealm] (RLMRealm.mm:396)

[segiddins]

Our latest hunch is that these assertion failures are cause when trying to open up a Realm file that has been corrupted. It would be helpful to see the Realm files in question, if at all possible. Thanks!

[jpsim]

Just following up on this request for an Xcode project that could help use reproduce this issue, or the corrupt realm files, @voidref and @IGZjuantrias.

[voidref]

@jpsim I sent off a zip to the help address attn @segiddins 21 days ago.

[jpsim]

Ah yes, my mistake @voidref. We've been working on that case.

Our support tooling doesn't link emails with GH issues very well at the moment so this was still marked as needing a follow up.

[voidref]

No worries @jpsim, better to unnecessarily follow up than lose something!

[lattejed]

Hey there,

I'm seeing this in a client's app as well. We were having a hard time tracking it down since it happens too early in the app's lifecycle for Crashlytics to get a report out. By chance my client had it happen on his phone and by recreating the conditions on my phone I managed to get it to crash while attached to a debugger.

The steps to recreate it:

1. Run the app (calling setDefaultRealmPath() and setSchemaVersion())
2. Put the app in the background
3. Reboot the device (by holding the power and home buttons)
4. Run the app again

The output is similar to the one above:

group.cpp:135: [realm-core-0.88.0] Assertion failed: size_t(m_top.get(2) / 2)<=m_alloc.get_baseline() ... IMPORTANT: if you see this error, please send this log to help@realm.io.

I would say it's likely a corrupt file as well.

Also:

Is this being actively worked on and is there an ETA for a fix?

[jpsim]

Is this being actively worked on and is there an ETA for a fix?

Yes, we've been looking at the corrupt realm files, but it's taking a long time because we have yet to be able to create a reproducible case.

I've tried making an app that calls setDefaultRealmPath() and setSchemaVersion() and following the steps you've posted, but I could reproduce it then either.

Since you have a reproducible sample, could you send us code to repro so we can fix this? You can email us privately at help@realm.io if you can't boil it down to a minimal case and your app has sensitive code.

[lattejed]

Hey, thanks for looking at this right away. A few more points that may help:

1. This app is using an app group and containerURLForSecurityApplicationGroupIdentifier()
2. The crash actually occurs during the first read with objectsWithPredicate()
3. This has to be on the device -- following the same steps on the sim doesn't seem to work

I'll see if I can put together a minimal case that crashes as well. If not I'll talk to my client about shipping you the whole project.

[jpsim]

We've now been able to reproduce this issue and are working on identifying the root cause. We will post back here once we know more.

[lattejed]

Thanks for the update.

[zpapp]

Could we get an ETA on this? We are in the process of preparing a "critical bug fixes" release and this would be a prime candidate, if we don't have to wait too long...

[ricisa]

I"m waiting on a fix still. Any update guys?

[jpsim]

As of today, we now have a PR in Realm's core which addresses this issue and should be merged soon.

We'll update this issue with any further progress. Thanks for your patience!

For internal reference: https://github.com/realm/realm-core/pull/875 (private repo)

[zpapp]

Thanks for the update @jpsim . Do you happen to know what this means in term of release timeline? When will you publish a new version of Realm that has this fix?

[jpsim]

We just released 0.93.2 which includes a fix for this issue. Please try that and let us know how it goes!

Thanks for your patience while we worked to address this problem.

[zpapp]

@jpsim thank you!

[ncperry]

We are seeing this issue with our users. We are on Realm Version 0.94.1. Is there anything that we can do on our end to mitigate this?

[jpsim]

@ncperry this assertion gets triggered when the logical size on disk of the realm file is larger than the size expected by the file (this size is written as part of the file structure). As mentioned in my last comment, we've taken measures to ensure this never happens as of 0.93.2, but since you've seen this in 0.94.1, I'd love to know if the file was ever written to using a version of Realm prior to 0.93.2.

If an older version of Realm caused file corruption, that file will stay corrupted even accessed by newer versions of Realm.

So if the file was corrupted while being accessed by Realm < 0.93.2, we're aware of that issue and have resolved it. If the initial corruption happened with a version of Realm > 0.93.2, this is the first time we've heard of the issue resurfacing and would love to see code that can reproduce the issue so we can troubleshoot further.

In any case, the only way to get data back from the corrupted file will be to send it to us at help@realm.io for recovery.

[ncperry]

The databases could very well have been created on an old version of Realm. Our latest version changed the Realm version from 0.91.4 to 0.94.1.

We'll make sure that old Realm files get deleted. (We use realm for caching information from a server. We can re-download anything we need.) And see if that solves the issue.

Thanks for your help.