• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Large Core Data memory allocations for small rows
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Large Core Data memory allocations for small rows


  • Subject: Re: Large Core Data memory allocations for small rows
  • From: Benjamin Rister <email@hidden>
  • Date: Wed, 7 Jan 2009 23:02:14 -0500

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 (email@hidden)

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Large Core Data memory allocations for small rows
      • From: Benjamin Rister <email@hidden>
References: 
 >re: Large Core Data memory allocations for small rows (From: Ben Trumbull <email@hidden>)

  • Prev by Date: Re: How to obtain icon displayed by Finder for a file
  • Next by Date: Re: -[NSView window] returns nil if its NSTabView not selected
  • Previous by thread: re: Large Core Data memory allocations for small rows
  • Next by thread: Re: Large Core Data memory allocations for small rows
  • Index(es):
    • Date
    • Thread