Hi Ben,
Thanks for the response. I'm rearranging your email a bit to respond
to pertinent bits in one place:
The stack trace is:
5 <our code>
4 CoreData -[_NSFaultingMutableSet objectEnumerator]
3 CoreData -[_NSFaultingMutableSet willRead]
2 CoreData -[NSManagedObjectContext(_NSInternalAdditions)
_retainedObjectWithID:optionalHandler:withInlineStorage:]
1 CoreData +
[NSManagedObject(_PFDynamicAccessorsAndPropertySupport)
allocWithEntity:]
0 CoreData _PFAllocateObject
This is allocating an object across a to-many relationship.
Or the stack trace here could be computed incorrectly. If the stack
trace were off slightly, then a hypothetically reasonable allocation
would be for the CFSet holding the contents of the to-many
relationship, assuming it had 50-100 thousand entries.
The stack trace seems right to me, as far as I can tell. A to-many
relationship set with the ~8K instances of this object in it has
objectEnumerator called on it, and it's the first time this row data
is ever accessed. There are ~6500 malloc instances back-to-back with
this stack trace before it runs out of 32-bit VM and crashes, so it
seems pretty clear that those are supposed to be the individual
managed objects.
It could be a bug in Core Data, or a memory smasher in your app that
corrupts either our data structures or the ObjC runtime structures.
malloc_history and libgmalloc (see man page) may help produce some
more information.
All of this information comes from analysis under Instruments, which
is the same data malloc_history gives as far as I know.
Our usual zombified runs produce no instances of bad memory hygiene of
that sort, and I just ran the app under guard malloc and it produced
no complaints until running out of VM (as expected).
If you can reproduce this in a sample project with your model, you
should definitely file a bug. If you can attach your program and
steps to reproduce, you could file a bug with that as well.
I've filed Radar 6480291 with the app, user's data file, and
instructions.
Thanks,
Benjamin Rister
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
