Segfault when applying permissions to a reference Realm

Goals

I’ve been trying to figure out how to lock down permissions and schemas for all objects and for all users, apart from admins.

In this case, I’m using a single global/shared Realm (reference type) that’s shared across multiple users.

To ensure that the Realm always exists, and exists as a reference type, I’m first opening it with fullSynchronization set to false (and passing in schemas, currently also Realm.Permissions.* schemas), subscribing for one object type and waiting for it to sync, then applying the permissions, unsubscribing, removing event handlers and closing the Realm.

Finally, I’m opening the Realm again, but this time with full sync, and skipping applying the permissions and naturally not using subscriptions either.

NOTE: If I simply open it once with full sync enabled, it’s created as a “full” type Realm, and without any system classes/schemas (unless I include those manually).

Expected Results

I expect to be able to apply permissions, or at least get an error/exception if something goes wrong.

Actual Results

Applying permissions does seem to work every now and again (perhaps 1/10 times?), but more often than not, it’ll simply segfault when trying to access anything permission related, such as this:

let results = realm.objects(Realm.Permissions.Class.schema.name)

Here’s the segfault dump/stacktrace:

PID 8243 received SIGSEGV for address: 0x14d1f3b80000
0   segfault-handler.node               0x00000001026de3c8 _ZL16segfault_handleriP9__siginfoPv + 312
1   libsystem_platform.dylib            0x00007fff5efaaf5a _sigtramp + 26
2   ???                                 0x0000000102862410 0x0 + 4337312784
3   realm.node                          0x0000000108e0450e _ZN5realm2js4wrapIXadL_ZNS0_16RealmObjectClassINS_4node5TypesEE12get_propertyEPN2v87IsolateENS6_5LocalINS6_6ObjectEEERKNS0_6StringIS4_EERNS0_11ReturnValueIS4_EEEEEEvNS9_INS6_6StringEEERKN3Nan20PropertyCallbackInfoINS6_5ValueEEE + 75
4   realm.node                          0x0000000108dd489f _ZN3Nan3impL29PropertyGetterCallbackWrapperEN2v85LocalINS1_4NameEEERKNS1_20PropertyCallbackInfoINS1_5ValueEEE + 167
5   node                                0x00000001005f7d61 _ZN2v88internal25PropertyCallbackArguments28BasicCallNamedGetterCallbackEPFvNS_5LocalINS_4NameEEERKNS_20PropertyCallbackInfoINS_5ValueEEEENS0_6HandleINS0_4NameEEENSC_INS0_6ObjectEEE + 401
6   node                                0x000000010067ba30 _ZN2v88internal12_GLOBAL__N_134GetPropertyWithInterceptorInternalEPNS0_14LookupIteratorENS0_6HandleINS0_15InterceptorInfoEEEPb + 512
7   node                                0x00000001006782c6 _ZN2v88internal6Object11GetPropertyEPNS0_14LookupIteratorE + 86
8   node                                0x00000001005e8feb _ZN2v88internal6LoadIC4LoadENS0_6HandleINS0_6ObjectEEENS2_INS0_4NameEEE + 747
9   node                                0x00000001005ec0c5 _ZN2v88internal11KeyedLoadIC4LoadENS0_6HandleINS0_6ObjectEEES4_ + 165
10  node                                0x00000001005f1661 _ZN2v88internal24Runtime_KeyedLoadIC_MissEiPPNS0_6ObjectEPNS0_7IsolateE + 401
11  ???                                 0x000031c5faddbe3d 0x0 + 54726387154493
[1]    8243 segmentation fault  node dist/lib

Steps to Reproduce

I’ve more or less outlined the process above, under “Goals”, but using the sample code below should suffice in replicating it, unless it’s environment/tool specific.

If necessary, I may be able to attempt to provide a simple repro case, but can’t guarantee I can reproduce it outside of this project.

Code Sample

I’m more or less using the sample code available here: https://github.com/realm/realm-server-side-samples/tree/master/21-Permission

In case it matters, my logic does use a lot more async/await/Promises.

Version of Realm and Tooling

• Realm JS SDK Version: 2.20.1
• Node or React Native: Node v10.13.0 (+ TypeScript)
• Client OS & Version: macOS 10.13.6
• Which debugger for React Native: None

[Dids]

I’ve definitely updated dependencies on all sides (server, clients), but things like OS and Node.js version have stayed the same. I’ll keep an eye on it and reopen if it resurfaces. 😃

[Dids]

Just an update on this that I’m no longer getting this. Can’t say for sure when it stopped, but it’s definitely been crash-free for a month or two.