realm-swift
realm-swift copied to clipboard
realm
EXC_BAD_ACCESS in RLMGetThreadLocalCachedRealmForPath
How frequently does the bug occur?
Sometimes
Description
The app is seeing crashes due to an EXC_BAD_ACCESS "Attempted to deference null pointer in" RLMGetThreadLocalCachedRealmForPath when attempting to lock the realm cache mutex.
RLMRealmUtil:L58
RLMRealm *RLMGetThreadLocalCachedRealmForPath(std::string const& path, void *key) {
std::lock_guard<std::mutex> lock(s_realmCacheMutex);
This is specifically happening on iOS 14 devices.
Stacktrace & log output
2 BananaApp
__mutex_base:91:27
lock_guard
3 BananaApp
RLMRealm.mm:429:35
+[RLMRealm realmWithConfiguration:queue:error:]
4 BananaApp
BaseService.swift:21:29
one-time initialization function for realm
8 BananaApp
BaseService.swift:21:16
static BaseService.dataMergedWithExisting(metadata:key:data:)
Can you reproduce the bug?
Not yet
Reproduction Steps
No response
Version
10.24.1
What SDK flavour are you using?
Local Database only
Are you using encryption?
No, not using encryption
Platform OS and version(s)
iOS 14 (14.0-14.8.1)
Build environment
Xcode version: 13.2 Dependency manager and version: Cocoapods
At this point in the debugging process, I'm not sure if this an issue with Realm or with how Realm is configured in my application, so I'd like to better understand what could cause an exception to be thrown here?
Is this possibly happening while the app is in the process of exiting? That line of code is a very mundane of a static variable, which means that it could fail if it's happening while or after the exit-time destructors run to tear down global variables.
If it's not something along those lines, then either the reported crash location is incorrect or something has previously gone very wrong and this is just the point where it finally results in a crash.
Would the destructors be called when creating a new Realm in a closure? Since our user object can be accessed on any thread, we have a singleton where we retrieve it like so:
var user: User? {
get {
do {
return try Realm(configuration: BaseService.realmConfiguration).object(ofType: User.self, forPrimaryKey: userId)
} catch {
...
return nil
}
}
Otherwise, the app itself doesn't seem to be in the process of exiting when the crash occurs.
No, the mutex's lifetime is from when the first time the function is called until app shutdown.
Hi @kondratyevdev are you experiencing the same crash, can you attached a more detailed stacktrace?
@dianaafanador3
Why it happens I cannot understand :( I tried to create and work with Ream only in one thread, but it didn't help.
- [ ] > Thread 14 Crashed:
- [ ] > 0 libsystem_pthread.dylib 0x00000001e4a1e744 _pthread_mutex_fairshare_unlock + 104 (pthread_mutex.c:1031)
- [ ] > 1 libc++.1.dylib 0x00000001ad962af4 std::__1::mutex::lock() + 16 (__threading_support:397)
- [ ] > 2 FaceAppAssets 0x0000000103befc54 lock_guard + 8 (__mutex_base:91)
- [ ] > 3 FaceAppAssets 0x0000000103befc54 lock_guard + 8 (__mutex_base:91)
- [ ] > 4 FaceAppAssets 0x0000000103befc54 RLMGetThreadLocalCachedRealmForPath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, void*) + 44 (RLMRealmUtil.mm:58)
- [ ] > 5 FaceAppAssets 0x0000000103be8594 +[RLMRealm realmWithConfiguration:queue:error:] + 256 (RLMRealm.mm:429)
As @tgoyne mentioned above, because the mutex is and static variable, this can only happen if the app is exiting which means the mutex is deallocated, before running your code. Can you reproduce it?, Can you please paste the complete stack trace for this? Or explain the particularly use case for this crash.
Hi @dianaafanador3,
Same issue here. This happened in AppDelegate didFinishLaunchingWithOptions, we init a Realm instance in the background queue and use file coordinator to get something from the DB. This crash happened repeatedly on some iOS 14 users at the first second of a session.
Sadly I still can't reproduce this, below is the stack trace.
Crashed: com.apple.root.default-qos
0 libsystem_pthread.dylib 0x7744 pthread_mutex_lock + 102
1 libc++.1.dylib 0x3caf4 std::__1::mutex::lock() + 16
2 Realm 0xd5988 RLMGetThreadLocalCachedRealmForPath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, void*) + 59 (RLMRealmUtil.mm:59)
3 Realm 0xce4b8 +[RLMRealm realmWithConfiguration:queue:error:] + 394 (RLMRealm.mm:394)
4 RealmSwift 0x40870 Realm.init(configuration:queue:) + 4402759792 (<compiler-generated>:4402759792)
5 WhoscallProduction 0x4754c closure #1 in closure #1 in PersonalBlockingDBHelper.getEntryCount() + 347 (PersonalBlockingDBHelper.swift:347)
6 WhoscallProduction 0x21c378 thunk for @callee_guaranteed () -> (@error @owned Error) + 4372906872 (<compiler-generated>:4372906872)
7 WhoscallProduction 0x48830 partial apply for thunk for @callee_guaranteed () -> (@error @owned Error) + 4370991152 (<compiler-generated>:4370991152)
8 WhoscallProduction 0x48ea4 thunk for @callee_guaranteed () -> (@error @owned Error)partial apply + 4370992804
9 libswiftObjectiveC.dylib 0x1f24 autoreleasepool<A>(invoking:) + 64
10 WhoscallProduction 0x48d50 partial apply for closure #1 in PersonalBlockingDBHelper.getEntryCount() + 4370992464
11 WhoscallProduction 0x1d83c0 thunk for @callee_guaranteed (@in_guaranteed URL) -> () + 4372628416 (<compiler-generated>:4372628416)
12 WhoscallProduction 0x1d8444 thunk for @escaping @callee_guaranteed (@in_guaranteed URL) -> () + 4372628548 (<compiler-generated>:4372628548)
13 Foundation 0x61780 -[NSFileCoordinator _invokeAccessor:thenCompletionHandler:] + 100
14 Foundation 0x1e0308 __73-[NSFileCoordinator coordinateWritingItemAtURL:options:error:byAccessor:]_block_invoke + 132
15 Foundation 0x1e1808 __85-[NSFileCoordinator(NSPrivate) _coordinateWritingItemAtURL:options:error:byAccessor:]_block_invoke.350 + 268
16 Foundation 0x61a58 -[NSFileCoordinator(NSPrivate) _withAccessArbiter:invokeAccessor:orDont:andRelinquishAccessClaim:] + 620
17 Foundation 0x63cc0 -[NSFileCoordinator(NSPrivate) _coordinateWritingItemAtURL:options:error:byAccessor:] + 784
18 Foundation 0x63988 -[NSFileCoordinator coordinateWritingItemAtURL:options:error:byAccessor:] + 120
19 WhoscallProduction 0x473e8 PersonalBlockingDBHelper.getEntryCount() + 344 (PersonalBlockingDBHelper.swift:344)
20 WhoscallProduction 0x136e64 closure #1 in AppDelegate.updateUserProperties() + 639 (AppDelegate.swift:639)
21 WhoscallProduction 0x23d7c8 thunk for @escaping @callee_guaranteed () -> () + 4373043144 (<compiler-generated>:4373043144)
22 libdispatch.dylib 0x2a54 _dispatch_call_block_and_release + 32
23 libdispatch.dylib 0x47ec _dispatch_client_callout + 20
24 libdispatch.dylib 0x7938 _dispatch_queue_override_invoke + 756
25 libdispatch.dylib 0x15fb0 _dispatch_root_queue_drain + 388
26 libdispatch.dylib 0x167a8 _dispatch_worker_thread2 + 112
27 libsystem_pthread.dylib 0x3768 _pthread_wqthread + 216
28 libsystem_pthread.dylib 0xa74c start_wqthread + 8
same here. Any news or workarounds to the issue? I experience the same:
- Crash as soon as initialize
Realm, same line and similar stack trace - iOS 14 users
- Can't seem to reproduce in the simulator
same here with same line and similar stack trace
- 22 of 24 of crashes happens in 1 seconds, 1 in 2 seconds.
- iOS 14 users
- Can't seem to reproduce.
We found we changed RealmSwift version from 10.22.0 to 10.25.1, right after this change and release, this crash started. before this change there was 0 crash related to this. Hope this info might be helpful?
Like @fangmobile and @fermoyadrop, we are seeing this crash only on launch and only on iOS 14. We haven't been able to reproduce the issue.
We are seeing a similar crash.
- realm-cocoa 10.20.2
- Only happens on iOS 14
- Only happens when app is installed through App Store. Installing the same build through TestFlight does not crash. Rebuilding the app with an enterprise account and running the app does not crash.
0 libsystem_pthread.dylib 0x00000001d43fa22c pthread_mutex_lock$VARIANT$armv81 + 0
1 libc++.1.dylib 0x00000001a00279b8 std::__1::mutex::lock+ 244152 () + 12
2 XXXXXXXXX 0x0000000105bf7820 RLMGetThreadLocalCachedRealmForPath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, void*) + 1980448 (RLMRealmUtil.mm:59)
3 XXXXXXXXX 0x0000000105bf00c0 +[RLMRealm realmWithConfiguration:queue:error:] + 1949888 (RLMRealm.mm:429)
4 XXXXXXXXX 0x0000000105c82ae8 Realm.init(configuration:queue:) + 2550504 (Realm.swift:92)
HI @koneksa-sunny are you trying to access the realm from AppDelegate.didFinishLaunchingWithOptions, are you using a different thread to access the realm?
FYI: the issue stopped to reproduce for us when we switched back to the legacy build system in older xcode.
HI @koneksa-sunny are you trying to access the realm from
AppDelegate.didFinishLaunchingWithOptions, are you using a different thread to access the realm?
@dianaafanador3 I am accessing Realm in AppDelegate.didFinishLaunchingWithOptions on the Main thread. The code has not changed in 2+ years.
This is something we've encountered as well. Only an iOS 14 bug. Updating the OS is not an option for most of our users without IT support, so a workaround at least would be nice.
Same her. iOS 14 only, no reproduction, no code changes in my realm conf since long time, last version 10.30.0
Same here. iOS14 only. This started when we upgraded from 10.13.0 to 10.28.5
Seeing the same as described here since updating RealmSwift from 10.29.0 to 10.32.2 last week.
Same crash, function crashing at line 59 of RLMGetThreadLocalCachedRealmForPath
https://github.com/realm/realm-swift/blob/9f7a605dfcf6a60e019a296dc8d91c3b23837a82/Realm/RLMRealmUtil.mm#L59
with EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000.... null ptr
RLMGetThreadLocalCachedRealmForPath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, void*) + 59
must be either s_realmsPerPath, path, or key.
s_realmsPerPath - https://github.com/realm/realm-swift/blob/9f7a605dfcf6a60e019a296dc8d91c3b23837a82/Realm/RLMRealmUtil.mm#L39 looks globally instantiated and has not changed in 3 years. unlikely to be the culprit.
key appears to originate from https://github.com/realm/realm-swift/blob/28c488974f544c9affc4eacdd5b9dfc6785ebbc0/Realm/RLMRealm.mm#L465
which appears like a safe operation, however it was changed in this pr here from just 7 months ago
https://github.com/realm/realm-swift/pull/7789/files#diff-a98a6c3989e1668cf28dbcb829199452024a880dced23fc11060ba13b113989dR443
This doesn't explain occurrences before may 10th however.
may 4th this change occurred in the same vicinity https://github.com/realm/realm-swift/pull/7778/files#diff-a98a6c3989e1668cf28dbcb829199452024a880dced23fc11060ba13b113989dR409
so it appears that near that timeframe a lot of adjustments were being made in relation to the code that's crashing. Still haven't found evidence of what may have caused this in april but i suspect someone at realm could put together the pieces from here.
Interesting, did not notice this at first, OP reported line 58, but myself and some previous folks reported line 59, possibly these are 2 different crashes.
https://github.com/realm/realm-swift/issues/7741#issuecomment-1119317472 https://github.com/realm/realm-swift/issues/7741#issuecomment-1171563125
We're seeing the same crash. iOS 14 only. We upgraded from 10.11.0 to 10.32.2 Does anyone now if only migrated users or only new or all users are affected by this? Would be interesing if it can be fixed by reinstalling the app. Simulator is working fine.
Can this be related to cocoapods? We couldn't upgrade to a version later than 10.11.0 as it crashed on iOS 12 devices, but this issue was occurring with cocoapods only.
So far 100% of the iOS 14 users seeing this crash, are new users. None of them was migrating from a previous installation.
Ok, we can confirm again: only new users are affected. Also we released a version using realm with SPM instead of cocoapods and the crash doesn't happen there.