Open thegreenline opened 2 years ago
ejm01
commented
2 years ago Are you bundling the realms on device before being opened? I'm wondering because there appears to be a schema change needed. Perhaps the schemas got mismatched between the two and the schema change isn't being handled correctly?
thegreenline
commented
2 years ago I also think it's a schema problem, but I did the migration from v1 of the shema with separate "if" and not "if else if". For the transition to the new version I also updated the IDs of the objects that seemed not to work. But I don't understand because all the versions are managed correctly and I never had such problems (no passage in the catch block)
ejm01
commented
2 years ago I don't think I understand either, but it doesn't seem like you're doing anything incorrectly. Are you able to provide a .zip with a reproduction? It's hard to resolve this without more information.
thegreenline
commented
2 years ago The problem is that I can't reproduce the crashes either with the Testflight versions or with the local versions. I just have crash feedbacks without any other information than this kind of stuff
If I open the stack trace from Xcode Organizer crash report, I can found the exception, but nothing more
The migration is done directly in the AppDelegate(didFinishLaunchingWithOptions) before anything else.
My migration blocks are like
if oldSchemaVersion < 15 {
do migration
}
if oldSchemaVersion < 16 {
do migration
}
if oldSchemaVersion < 17 {
do migration
}It's quite possible that it's a migration problem, but I don't even have an error in the catch block of the try Realm...
thegreenline
commented
2 years ago If have a crash trace with "more infos"
Since upgrading from 10.5 to 10.25, my migration block does only
if oldSchemaVersion < 17 {
newObject!["id"] = UUID().uuidString
}did I miss something ?
(This is still the trace I get from a crash in production via Xcode organizer, still no local reproduction) It seems that crashes occur when the user has many objects in the database
pavel-ship-it
commented
2 years ago Hi @thegreenline , Are you adding the primary key field to the schema?
thegreenline
commented
2 years ago I have set the primaryKey only in the Realm object with
override static func primaryKey() -> String? {
return "id"
}Looks like I have a reproduction for that issue.
Just to confirm.
newObject!["id"] = UUID().uuidString
In this line the newObject is getting the value for newly added primary key field? Am I rignt?
thegreenline
commented
2 years ago newObject get a new ID UUID().uuidString return a string UUID.
I’m not getting the old object id, but I dont remember why
maybe: cant get old obejct ID, or just cant apply a empty migration to update Realm from 10.4 to 10.25 (10.4 format not compatible with current version of Realm studio). But my ID had alway been a non optionnal String with a UUID()uuidString as value.
The Id is only used to avoid duplicates, it has no other impact on the data
nbapps
commented
2 years ago Hi
I have new error for this crash from crashlitics, realm v 10.28.3
Plantage : com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000000
Crashed: com.apple.main-thread
0 libsystem_pthread.dylib 0x7744
nbapps
commented
2 years ago And from Xcode, I have this 2
How frequently does the bug occur?
Sometimes
Description
App crashes sometime in production since I updated Realm to be compatible with the new version of Realm Studio. The problem is that the app crashes instead of going into the block... I can't reproduce on my devices...
Stacktrace & log output
Can you reproduce the bug?
Not yet
Reproduction Steps
No response
Version
10.25.2
What SDK flavour are you using?
Local Database only
Are you using encryption?
No, not using encryption
Platform OS and version(s)
iOS 13 min target, but all crash on iOS 15.x
Build environment
Xcode version: 13.3.1 Dependency manager and version: Cocoapods 1.11.2