SERIOUS BUG: Xcode 4.3.2 creates invalid .momd resources
Originator: | craig.hockenberry | ||
Number: | rdar://11184500 | Date Originated: | |
Status: | Open | Resolved: | |
Product: | Developer Tools | Product Version: | 4.3.2 / 4E2002 |
Classification: | Serious Bug | Reproducible: | Always |
Summary: A versioned .xcdatamodeld bundle that is compiled with MOMC results in a .momd resource bundle which crashes NSManagedObjectModel's -initWithContentsOfURL: Steps to Reproduce: 1) Create a versioned Data Model (.xcdatamodeld) using Xcode 4.3.2 running on Lion. 2) Compile the application. 3) Load the resource for the compiled Data Model (.momd) using NSManagedObjectModel's -initWithContentsOfURL: See the attached project: http://files.iconfactory.net/craig/bugs/Vershunning.zip The sample project loads the unversioned Data Model (AccountDocument.mom) and the data model compiled with Xcode 4.2 (AccountDocument2.momd). It crashes with the data model compiled with Xcode 4.3 (AccountDocument3.momd). Expected Results: The application should load the managed object model. Actual Results: The application crashes with EXC_BAD_ACCESS while loading the data in the .momd resource. The stack trace is: * thread #1: tid = 0x2103, 0x00007fff931d9350 libobjc.A.dylib`objc_msgSend_vtable13 + 16, stop reason = EXC_BAD_ACCESS (code=13, address=0x0) frame #0: 0x00007fff931d9350 libobjc.A.dylib`objc_msgSend_vtable13 + 16 frame #1: 0x00007fff8935e975 CoreData`-[NSKnownKeysDictionary1 _setValues:retain:] + 197 frame #2: 0x00007fff8935f288 CoreData`_newReadModelFromBytes + 648 frame #3: 0x00007fff8935b93e CoreData`+[NSManagedObjectModel(_NSManagedObjectModelPrivateMethods) _newModelFromOptimizedEncoding:error:] + 9310 frame #4: 0x00007fff89359451 CoreData`-[NSManagedObjectModel(_NSManagedObjectModelPrivateMethods) initWithContentsOfOptimizedURL:] + 305 frame #5: 0x00007fff89358d7b CoreData`-[NSManagedObjectModel initWithContentsOfURL:] + 443 frame #6: 0x000000010edb43da Vershunning`-[AppDelegate applicationDidFinishLaunching:] + 554 at AppDelegate.m:54 Regression: The same code works fine on Xcode 4.2 on Snow Leopard. Also, if the .momd resources that are compiled with 4.2 are used in the project as a Copy Files build phase (instead of having MOMC generate them) the application works fine. Notes: If you'd like to see the history of events that led up to this report, check out this StackOverflow question: http://stackoverflow.com/questions/10001026/lightweight-migration-of-a-nspersistentdocument ---- Appended the following information on 4/4/2012: The compiled .momd resources can be loaded after the "existingPartner" fetch request is changed from: name == $name to: name == $NAME Your mission, should you choose to accept it, is to figure out why a part of the object model that does not affect the persistence of data breaks versioning and lightweight migration. It's clear from the documentation that this should not be the case: "Core Data’s perspective on versioning is that it is only interested in features of the model that affect persistence."
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
Duped as rdar://11209322
Duped as rdar://11184675