Crash inside RLMIsObjectSubclass

[molind]

Goals

Open realm.

Expected Results

No crash

Actual Results

Crash

Crashed: com.apple.root.user-initiated-qos
0  libobjc.A.dylib                0x18235361c class_getSuperclass + 4
1  GalileoPro                     0x1009461d8 RLMIsObjectSubclass (RLMUtil.hpp:70)
2  GalileoPro                     0x1009b84b4 RLMRegisterClassLocalNames(objc_class**, unsigned long) (RLMSchema.mm:104)
3  GalileoPro                     0x1009b8d44 +[RLMSchema sharedSchema] (memory:2803)
4  GalileoPro                     0x1009ae41c +[RLMRealm realmWithConfiguration:error:] (RLMRealm.mm:425)
5  GalileoPro                     0x1008168fc __31-[DataSource initDefaultRealm:]_block_invoke_2 (DataSource.mm:758)
6  libdispatch.dylib              0x182a8aa54 _dispatch_call_block_and_release + 24
7  libdispatch.dylib              0x182a8aa14 _dispatch_client_callout + 16
8  libdispatch.dylib              0x182a97ea4 _dispatch_root_queue_drain + 1032
9  libdispatch.dylib              0x182a97a38 _dispatch_worker_thread3 + 120
10 libsystem_pthread.dylib        0x182d3306c _pthread_wqthread + 1268
11 libsystem_pthread.dylib        0x182d32b6c start_wqthread + 4

More details at: http://crashes.to/s/a2cb0314979

Steps to Reproduce

It's our top crash now, it's happened at 0.5% of daily users.

Code Sample

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
        NSError *error = nil;
        [RLMRealm realmWithConfiguration:config error:&error];
        // commented 
    });

Version of Realm and Tooling

Realm framework version: Realm-cocoa 3.1.1

Realm Object Server version: 2.7.2

Xcode version: 9.2

iOS/OSX version: iOS 11 and iOS 10

Dependency manager + version: Cocoapods 1.4.0

[bdash]

Based on the crash log, class_getSuperclass is being called with an invalid value (perhaps a pointer to deallocated memory, or perhaps a pointer that was never valid at all?). The Realm code that calls class_getSuperclass in this case does so on each class returned by objc_copyClassList with virtually no intervening logic. This suggests that the Objective-C runtime itself is returning the invalid Class instance, and Realm just happens to be crashing by virtue of enumerating all Objective-C classes to detect Realm model classes. Given that the crash appears to be caused by invalid state elsewhere in your process, I'm not sure that there's anything specific that we can do to address this.

My suggestion would be to attempt to reproduce this locally. Guard Malloc or Malloc Scribble could be useful tools in doing this. Once this is accomplished, Malloc Stack Logging would help you determine whether the faulting address was once a valid allocated address, and where it came from. This may help pinpoint what's gone wrong.

[WangChaooooo]

Facing this crash now. Have u fixed this bug now???

[tgoyne]

There is nothing we can do here without a repro case.

[BernardGatt]

This issue is currently our top crash as well, we're still experiencing it on v3.6.

[mohammedDehairy]

we have this crash also and it might be helpful to know that we have firebase performance which has FirebaseSwizzlingUtilities as a dependency, which does some method/class runtime manipulation I suppose, so is it possible that FirebaseSwizzlingUtilities can cause this crash?

[tgoyne]

If they're ever calling class_setSuperclass() then crashes would be unsurprising, but simple method swizzling and the like shouldn't cause problems when walking the class hierarchy.

[mohammedDehairy]

Thanks for the replay @tgoyne , what we did in the hope of fixing the crash is create the Realm with configuration on the main thread instead of a Serial background queue, could this possibly fix the crash? or is there any other suggestion or a workaround?

[realm-probot]

Hey - looks like you forgot to add a T:* label - could you please add one? 👍

[vitosubXX]

I can easily reproduce this crash when I use Realm in a custom framework :

1. Create a custom framework (named MyKit.framework) which is added by Cocoapods.
2. Link the MyKit.framework to MyProject.xcodeproj.
3. Create a subclass of RLMObject in MyProject (named MyObj).
4. Init the Realm used RLMRealmConfiguration -setObjectClasses in the AppDelegate -didFinishLaunch (main thread)

Then, it will crash cause the method RLMIsObjectSubclass(), and also log "Can't add non-Object type 'xxxxxx' to a schema."

[Lukasz2891]

Is there any progress with that issue?

I also suppouse that's caused by FirebaseSwizzlingUtilities used in the FirebasePerformance framework.

Maybe something like that would help?
https://blog.timac.org/2016/1124-testing-if-an-arbitrary-pointer-is-a-valid-objective-c-object/

[bswaidner]

Any updates? Starting to see this crash more often

[hibernat]

We also face to this issue. Before having FirebasePerformace in the project, we had no these crashes.

[walsht]

Anyone find a workaround for this issue?

[mohammedDehairy]

What helped for us is disable firebase automatic measurements like _app_start, automatic UIViewControllers loading time, and networking monitoring (Firebase performance): Performance.sharedInstance().isInstrumentationEnabled = false Apparently to implement automatic firebase measurements they had to do a lot of swizzling, and if disabled, the conflict with Realm is resolved. Hope this helps!

…

On Tue, Mar 26, 2019 at 2:54 PM Tim Walsh ***@***.***> wrote: Anyone find a workaround for this issue? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5618 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACf6HVbiG1fDjace7-aJbwjA4VciE8_Cks5vaiZ7gaJpZM4SIRSR> .

[walsht]

We will try that... Thanks @mohammedDehairy

[andre-alves-movile]

Having the same issue and we also use FirebasePerformance...
@walsht Did it worked for you disabling FirebasePerformance?

[hibernat]

Performance.sharedInstance().isInstrumentationEnabled = false works to me! Thanks a lot!

[sysail]

I have lots of crash now. I decide to use FMDB instead of Realm since the isssue is still open.

[julianD77]

Hey, thanks for the suggestions regarding disabling the instrumentation and/or the automatic Firebase measurements.

Can anyone confirm however whether it is required to disable ALL Firebase Performance Monitoring functionality, and therefore you cannot to receive any benefit of Firebase Performance Monitoring if we are using Realm?

Or when you mentioned "disable firebase automatic measurements like app_start" @mohammedDehairy does that suggest that custom tracing still works for you?

I also wondered (although Im not too hopeful) whether disabling the monitoring SDK at build time but enabling it at runtime using Performance.sharedInstance().isInstrumentationEnabled = true might avoid the issue?

Has anyone had any success in getting beyond this issue when using both Realm and the Firebase Performance Monitoring SDK in the same App? Thanks in advance for any input.

What helped for us is disable firebase automatic measurements like _app_start, automatic UIViewControllers loading time, and networking monitoring (Firebase performance): Performance.sharedInstance().isInstrumentationEnabled = false Apparently to implement automatic firebase measurements they had to do a lot of swizzling, and if disabled, the conflict with Realm is resolved. Hope this helps!
…
On Tue, Mar 26, 2019 at 2:54 PM Tim Walsh @.***> wrote: Anyone find a workaround for this issue? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5618 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ACf6HVbiG1fDjace7-aJbwjA4VciE8_Cks5vaiZ7gaJpZM4SIRSR .

[ianpward]

If someone can provide a reproduction case that would be very helpful in determining the cause of this crash along with an eventual fix if it is on the realm side

[julianD77]

Thanks @ianpward - will try. We are also going to try and confirm if the issue still occurs when using the latest Firebase PerfMon SDK with the latest Realm (v5 then, time permitting, 10).

We couldn't ever see or reproduce the issue ourself before we had to disable the Firebase monitoring, but some of our users did experience the same crash above re RLMObject.mm

[jsflax]

Hey @julianD77 , were you able to confirm this? If so (or if it's no longer relevant), we can close the issue.

[julianD77]

Sorry - I didn't see the earlier message prompting for an update. It's a WIP still to try out the latest Realm and Firebase Perf SDKs to see if the issue occurs. We just need to find time in our work and release schedule when we can try this out, rolling it out to just a small percentage of users to that it doesn't have a big impact if the issue is still there. I will comment here once we have more information.

[aehlke]

I am currently experiencing this crash. What info can I provide? Xcode 12.4, latest realm, recent firebase. Performance.sharedInstance().isInstrumentationEnabled = false is not helping.

[julianD77]

@aehlke Yes, could you post details of the specific versions of the Realm SDK and Firebase Performance Monitoring SDK that you are using please?

[raduncicen]

Though, i'm not capable of reproducing it, our users do get this crash.
My projects SDK versions are as below:

• Firebase/Performance (7.11.0):
• Realm (10.7.4):

Note:
The crash occurs only on user who are using IOS 12.5.1, 12.5.2, 12.5.3
Devices are iphone 6 and iphone 6 Plus

[wwwqewrvsg]

Realm crashes often.
My projects using:

• Firebase/Performance (8.2.0). (cocoapod)
• Realm (4.4.1). (Swift Package Manager)

Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x1b540b194 class_getSuperclass + 4
1 PADI 0x10094cfb4 RLMIsObjectSubclass + 37772
2 PADI 0x1009c52ac RLMRegisterClassLocalNames(objc_class**, unsigned long) + 530052
3 PADI 0x1009c5afc +[RLMSchema sharedSchema] + 532180
4 PADI 0x1009bb874 +[RLMRealm realmWithConfiguration:error:] + 490572
5 PADI 0x100b4ea48 specialized Realm.init(configuration:) + 233524
6 PADI 0x100b4c584 Realm.init(configuration:) + 224112
7 PADI 0x1007a91ac DatabaseRepositoryImpl.initRealm() + 39 (DatabaseRepositoryImpl.swift:39)
8 PADI 0x1007a9128 DatabaseRepositoryImpl.init() + 31 (DatabaseRepositoryImpl.swift:31)
9 PADI 0x100730d84 Components.internalDatabaseRepository.getter + 54 (Components.swift:54)
10 PADI 0x100733fa4 one-time initialization function for sessionRepository + 4301242276
11 libdispatch.dylib 0x1a055381c dispatch_client_callout + 20
12 libdispatch.dylib 0x1a05550b4 dispatch_once_callout + 32
13 libswiftCore.dylib 0x1a487797c swift_once + 48
14 PADI 0x100716090 specialized HomeViewController.init(nibName:bundle:) + 53 (Components.swift:53)
15 PADI 0x1007117f0 @objc HomeViewController.init(nibName:bundle:) + 4301101040 (:4301101040)
16 PADI 0x1007f20e0 closure #1 in TabViewViewModel.getTabbar() + 69 (TabViewViewModel.swift:69)
17 PADI 0x10076f7e0 TabViewController.setupTabbars(:) + 4301486048 (:4301486048)
18 PADI 0x10076f19c TabViewController.viewDidLoad() + 35 (TabViewController.swift:35)
19 PADI 0x10076f4b8 @objc TabViewController.viewDidLoad() + 4301485240 (:4301485240)
20 UIKitCore 0x1a2b31d04 -[UITabBarController initWithNibName:bundle:] + 200
21 PADI 0x100770868 specialized TabViewController.init(nibName:bundle:) + 4301490280 (:4301490280)
22 PADI 0x100770254 @objc TabViewController.init(nibName:bundle:) + 4301488724 (:4301488724)
23 PADI 0x100720cb8 SplashViewController.finishedCheckingAppUpdate() + 4301163704 (:4301163704)
24 PADI 0x100720e28 specialized thunk for @escaping @callee_guaranteed (@guaranteed SplashViewController, @guaranteed Error?) -> () + 4301164072 (:4301164072)
25 WeakableSelf 0x101dcdac4 $s12WeakableSelf0A0PAAE7weakifyyyqd__cyx_qd__tclFyqd__cfU_TA + 80
26 PADI 0x100721ca4 partial apply for thunk for @escaping @callee_guaranteed (@in_guaranteed Error?) -> () + 4301167780 (:4301167780)
27 PADI 0x10076b4b8 closure #1 in AnalyticsAPIImpl.getAnalyticsAndCaching(globalUUID:completion:) + 4301468856 (:4301468856)
28 PADI 0x10076b6d0 partial apply for thunk for @escaping @callee_guaranteed (@guaranteed PADIAnalytics?) -> () + 4301469392 (:4301469392)
29 PADI 0x10088be40 closure #1 in ObservableType.subscribe(onNext:onError:onCompleted:onDisposed:) + 4302650944
30 PADI 0x10088c030 partial apply for closure #1 in ObservableType.subscribe(onNext:onError:onCompleted:onDisposed:) + 4302651440
31 PADI 0x100846228 AnonymousObserver.onCore(:) + 4302365224
32 PADI 0x10088e5d0 ObserverBase.on(:) + 4302661072
33 PADI 0x10088e714 protocol witness for ObserverType.on(:) in conformance ObserverBase + 4302661396
34 PADI 0x10088d998 closure #1 in ObserveOnSerialDispatchQueueSink.init(scheduler:observer:cancel:) + 4302657944
35 PADI 0x10088e318 partial apply for thunk for @escaping @callee_guaranteed (@guaranteed ObserveOnSerialDispatchQueueSink, @in_guaranteed Event<A.ObserverType.Element>) -> (@out Disposable) + 4302660376
36 PADI 0x100881ec0 MainScheduler.scheduleInternal(:action:) + 4302610112
37 PADI 0x10088dc24 ObserveOnSerialDispatchQueueSink.onCore(:) + 4302658596
38 PADI 0x10088e5d0 ObserverBase.on(:) + 4302661072
39 PADI 0x10088e714 protocol witness for ObserverType.on(:) in conformance ObserverBase + 4302661396
40 PADI 0x1008aaa68 Sink.forwardOn(:) + 4302776936
41 PADI 0x1008af66c SwitchSinkIter.synchronized_on(:) + 4302796396
42 PADI 0x1008b0990 SynchronizedOnType.synchronizedOn(:) + 4302801296
43 PADI 0x1008af73c protocol witness for ObserverType.on(:) in conformance SwitchSinkIter<A, B, C> + 4302796604
44 PADI 0x1008a7208 partial apply for implicit closure #2 in implicit closure #1 in ShareWhileConnectedConnection.synchronized_subscribe(:) + 4302762504
45 PADI 0x1008a7178 partial apply for thunk for @escaping @callee_guaranteed (@in_guaranteed Event) -> () + 4302762360
46 PADI 0x1008a6028 ShareReplay1WhileConnectedConnection.on(:) + 4302757928
47 PADI 0x1008a5bfc protocol witness for ObserverType.on(:) in conformance ShareReplay1WhileConnectedConnection + 4302756860
48 PADI 0x1008aaa68 Sink.forwardOn(:) + 4302776936
49 PADI 0x100869d1c AnonymousObservableSink.on(:) + 4302511388
50 PADI 0x100869dfc protocol witness for ObserverType.on(:) in conformance AnonymousObservableSink + 4302511612
51 PADI 0x1008468c4 partial apply for implicit closure #2 in implicit closure #1 in AnyObserver.init(:) + 4302366916
52 PADI 0x10084639c AnyObserver.on(:) + 4302365596
53 PADI 0x10075a2a4 specialized closure #1 in closure #1 in closure #1 in closure #1 in ApiClientImpl.createRequest(requestURL:method:parameters:headers:errorHandler:parameterEncoding:parse:) + 223 (ApiClientImpl.swift:223)
54 PADI 0x10071ca40 thunk for @escaping @callee_guaranteed () -> () + 4301146688 (:4301146688)
55 libdispatch.dylib 0x1a0551a84 _dispatch_call_block_and_release + 32
56 libdispatch.dylib 0x1a055381c _dispatch_client_callout + 20
57 libdispatch.dylib 0x1a0561c70 _dispatch_main_queue_callback_4CF + 884
58 CoreFoundation 0x1a08e0398 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 16
59 CoreFoundation 0x1a08da270 __CFRunLoopRun + 2524
60 CoreFoundation 0x1a08d9360 CFRunLoopRunSpecific + 600
61 GraphicsServices 0x1b7f17734 GSEventRunModal + 164
62 UIKitCore 0x1a3354584 -[UIApplication _run] + 1072
63 UIKitCore 0x1a3359df4 UIApplicationMain + 168
64 PADI 0x1006a2538 main + 17 (AppDelegate.swift:17)
65 libdyld.dylib 0x1a0595cf8 start + 4

[Nahatakyan]

Any good news?

[raduncicen]

Unfortunately no :/
I did run into this crash on debug, but it happens randomly.
Until someone finds the reason behind it and reproduce it on will, no one will try to solve it :(
This is still the most frequent crash in my app

[jsflax]

@Nahatakyan @raduncicen are you on the latest version of Realm?

[Nahatakyan]

@jsflax in my case
Realm - 10.5.2
Performance - 8.4.0

[raduncicen]

I'm about to be :) It's in app review. @jsflax
I started have this crash after pod update around April or May.
Since then, I tried to update both realm and firebase performance a few times but it did not work.
Will see if it works this time or not, but i doubt it.

Firebase/Performance -> 8.6.0
RealmSwift -> 10.12.0

[jsflax]

Can either of you post a stack trace? Happy to reopen this and take a look if so.

[raduncicen]

I don't have it right now. Next time i will take a screenshot 👍

[Nahatakyan]

I can't catch this crash. It's from Crashlytics.

Crashed: com.apple.m
ain-thread
0 libobjc.A.dylib 0x1c1022eb8 class_getSuperclass + 4
1 Trebel 0x100c5c620 RLMIsObjectSubclass + 70 (RLMUtil.hpp:70)
2 Trebel 0x100cc61d8 RLMRegisterClassLocalNames(objc_class**, unsigned long) + 104 (RLMSchema.mm:104)
3 Trebel 0x100cc6a28 +[RLMSchema sharedSchema] + 2577 (memory:2577)
4 Trebel 0x100cba84c +[RLMRealm realmWithConfiguration:queue:error:] + 465 (RLMRealm.mm:465)
5 Trebel 0x100d0eca4 Realm.init(configuration:queue:) + 844048 (:844048)
6 Trebel 0x1007f2a9c TMDataBase.migrateFromDefaultRealmFile() + 228 (TMDataBase.swift:228)
7 Trebel 0x1007f2780 TMDataBase.().init() + 4309870464 (:4309870464)
8 Trebel 0x1007f380c @objc TMDataBase.().init() + 4309874700 (:4309874700)

[yutoyazaki]

Has anyone tried this approach? #7275 (comment)
Since this crash occurred in the production and I couldn't be reproduced on Xcode, I can't verify this will work.

[alanf]

Also experiencing this as a top crash in our app. Opened an issue with Firebase as well, hopefully it's possible to coordinate something that fixes or works around this issue.

[dwirandytlvk]

Any update, I have the same problem as well

[mr-grey]

+1

[dammy1984]

Any update.. I am facing this issue only in production environment and it is capturing through firebase.. Not able to reproduce the same in Debug build

[alexeyn-martynov]

Hi, everyone! Ran into this crash in my app recently. It appears that there is no crash at all if I pass objectTypes during the creation of the Realm.Configuration. Firebase Performance only performs ISA swizzling on their own objects, so using objectTypes to prevent all classes from being scanned by Realm seems like a logical approach.

Code to illustrate workaround:

let config = Realm.Configuration (
    fileURL: url,
    schemaVersion: 999,
    objectTypes: Self.getAllRealmObjectTypes()
)

static func getAllRealmObjectTypes() -> [RealmSwift.Object.Type] {
    [MyData.self,
    MyOtherData.self]
}

Thanks!

[thecashx]

Thanks to @haozhutw --answer link--

After searching for the whole google I came to their comment and it seems to be a fine solutions as checking the logs of the Method :

static void RLMRegisterClassLocalNames(Class *classes, NSUInteger count) 

actually invokes for every class at the time of initialisation of the app.

My app was having several crashes almost for like 1.5% users on a same line of code in pods file of Realm folder which was this :

BOOL RLMIsObjectSubclass(Class klass) {
    return RLMIsKindOfClass(class_getSuperclass(class_getSuperclass(klass)), RLMObjectBase.class);
}

Changing the configurations for the Class's sharedInstance for the classes Inheriting Object [ RealmSwiftObject ] in swft as :

class DBManager {

        var db: Realm?
        static let sharedInstance = DBManager()
        
        private init() {
            do {
                var config = Realm.Configuration.defaultConfiguration
                config.objectTypes = [DBDataModel.self]
                //self.db  = try? Realm() <-- Instead of this
                self.db = try Realm(configuration: config) <-- Using This
            } catch {
                print("Error occurred \(error)")
            }
        }
        
    }

Here DBDataModel is inherited from Object ( RealmSwiftObject ) i.e. the realm data models

The main motive is clear that Realm should not find multiple classes amongst the app and should stick to particular array of classes provided to it (as suggested in the mentioned answer) so that It wont have an option to execute several times where in some exceptions it gets nil value which makes the app Crash.

Hope This Helps, as I myself has seen no crash of particular reason after this possible fix.