Realm-js: Segfault when applying permissions to a reference Realm

Created on 29 Nov 2018  路  7Comments  路  Source: realm/realm-js

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
O-Customer P-1-Required T-Bug-Crash

All 7 comments

Just to update on this, I've confirmed that it's only happening locally on macOS, and not on linux (Ubuntu 16.04). I'm also seeing segfaults now when querying data from Realm with realm.objects(), as long as there is more than 1 result.

I'm definitely wondering if it's related to the version of Node or something, as I did somewhat recently update from 8.x to 10.x.
I'm clearing out caches and node-gyp files now, in an attempt to rebuild everything from scratch.

UPDATE: Nope, still segfaults even after rebuilding everything. I might consider downgrading Node, but on the other hand it might not even be the issue here.

I am no longer getting segfaults after downgrading Node.js from 10.x to 8.x.

@Dids Thanks for reporting and the effort to narrow down where the bug is. Do you encrypt the connect to Realm Object Server?

@kneth No, encryption isn't configured on the Node.js client at all.

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.

@Dids I am happy to hear. Did you update anything (not only Realm)?

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. :)

Was this page helpful?
0 / 5 - 0 ratings