Open realm.
No crash
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
It's our top crash now, it's happened at 0.5% of daily users.
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
NSError *error = nil;
[RLMRealm realmWithConfiguration:config error:&error];
// commented
});
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
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.
Facing this crash now. Have u fixed this bug now???



There is nothing we can do here without a repro case.
This issue is currently our top crash as well, we're still experiencing it on v3.6.
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?
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.
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?
Hey - looks like you forgot to add a T:* label - could you please add one? :thumbsup:
I can easily reproduce this crash when I use Realm in a custom framework :
Then, it will crash cause the method RLMIsObjectSubclass(), and also log "Can't add non-Object type 'xxxxxx' to a schema."
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/
Any updates? Starting to see this crash more often
We also face to this issue. Before having FirebasePerformace in the project, we had no these crashes.
Anyone find a workaround for this issue?
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 notifications@github.com wrote:
Anyone find a workaround for this issue?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/realm/realm-cocoa/issues/5618#issuecomment-476650484,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACf6HVbiG1fDjace7-aJbwjA4VciE8_Cks5vaiZ7gaJpZM4SIRSR
.
We will try that... Thanks @mohammedDehairy
Having the same issue and we also use FirebasePerformance...
@walsht Did it worked for you disabling FirebasePerformance?
Performance.sharedInstance().isInstrumentationEnabled = false works to me! Thanks a lot!
I have lots of crash now. I decide to use FMDB instead of Realm since the isssue is still open.
Hi
I have another crash now.
When I use firebase Appconfig, Crash it!
Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x1a58ad374 class_getSuperclass + 4
1 Realm 0x103c0934c RLMIsObjectSubclass + 60 (RLMUtil.hpp:60)
2 Realm 0x103c75b30 RLMThrowResultsError(NSString*) + 16720 (RLMSchema.mm:16720)
3 Realm 0x103c76374 RLMThrowResultsError(NSString*) + 18836 (memory:18836)
4 Realm 0x103c6a9e4 RLMRealmTranslateException(NSError* __autoreleasing*) + 2616 (RLMRealm.mm:2616)
5 RealmSwift 0x1040a7fe8 Realm.__allocating_init() + 4324900840 (<compiler-generated>:4324900840)
6 cashfeed 0x102aac990 closure #1 in AppConfigManager.insertFirebaseConfig(_:completed:) + 4301867408 (AppConfigManager.swift:4301867408)
7 cashfeed 0x102aad730 thunk for @callee_guaranteed (@unowned AppConfigManager.FirebaseRemoteConfig) -> (@error @owned Error) + 4301870896 (<compiler-generated>:4301870896)
8 cashfeed 0x102aaefe0 partial apply for thunk for @callee_guaranteed (@unowned AppConfigManager.FirebaseRemoteConfig) -> (@error @owned Error) + 4301877216 (<compiler-generated>:4301877216)
9 libswiftCore.dylib 0x1b2f76418 $sSTsE7forEachyyy7ElementQzKXEKF + 448
10 cashfeed 0x102aac81c AppConfigManager.insertFirebaseConfig(_:completed:) + 4301867036 (AppConfigManager.swift:4301867036)
11 cashfeed 0x102aac744 closure #1 in AppConfigManager.firebaseRemoteConfigSync(completed:) + 4301866820 (AppConfigManager.swift:4301866820)
12 cashfeed 0x102aac910 thunk for @escaping @callee_guaranteed (@unowned FIRRemoteConfigFetchStatus, @guaranteed Error?) -> () + 4301867280 (<compiler-generated>:4301867280)
13 libdispatch.dylib 0x1a5852610 <redacted> + 24
14 libdispatch.dylib 0x1a5853184 <redacted> + 16
15 libdispatch.dylib 0x1a5805190 <redacted> + 1044
16 CoreFoundation 0x1a5b045e4 <redacted> + 12
17 CoreFoundation 0x1a5aff5d8 <redacted> + 2004
18 CoreFoundation 0x1a5afeadc CFRunLoopRunSpecific + 464
19 GraphicsServices 0x1afa9f328 GSEventRunModal + 104
20 UIKitCore 0x1a9c0c63c UIApplicationMain + 1936
21 cashfeed 0x102687928 main + 4297521448 (Int+KiloUnit.swift:4297521448)
22 libdyld.dylib 0x1a5988360 <redacted> + 4
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 .
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
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
Most helpful comment
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 notifications@github.com wrote: