site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thanks - that helps a lot. Address map entries track what's used, not what's available to be used. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Oct 31, 2008, at 8:23 AM, Jay Levitt <lists-darwin-dev@jay.fm> wrote: Eric Gouriou wrote: On Oct 30, 2008, at 3:41 PM, Jay Levitt wrote: I'm seeing the same thing on my 16GB Mac Pro (early 2008, OS X 10.5.5). I'm getting crashes every few days in WindowServer or coreservicesd; MenuMeters and Activity Monitor say I've got plenty of available RAM (either unused or idle). system.log says: system.log.0.bz2:Oct 29 14:35:19 macpro com.apple.coreservicesd [89]: coreservicesd(89,0xa0220fa0) malloc: *** mmap(size=16777216) failed (error code=12) I suggest keeping top or Activity Monitor around and, when you see a large growth in RPRVT or when VSIZE gets around ~3GB, capture heap / vmmap / leaks Is there a way for me to keep an eye on the "largest contiguous block on the free list", or something like that? I haven't done any dev on Darwin, so I don't know much about debugging it. You can iteratively examine the process with one or more of several developer tools, and then look at the differences over time to track free space. This email sent to site_archiver@lists.apple.com