site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Back in May, Sean McBride wrote: Sometimes I see messages like: malloc: *** mmap(size=16883712) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Eric Jay Levitt _______________________________________________ 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/eric.gouriou%40pobox.com _______________________________________________ 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 30, 2008, at 3:41 PM, Jay Levitt wrote: and Eric Gouriou replied: I'd give vmmap a try and look for a VM fragmentation issue. 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) system.log.0.bz2:Oct 29 14:35:19 macpro coreservicesd[89]: coreservicesd(89,0xa0220fa0) malloc: *** mmap(size=16777216) failed (error code=12)\n*** error: can't allocate region\n*** set a breakpoint in malloc_error_break to debug system.log.0.bz2:Oct 29 14:35:19 macpro com.apple.coreservicesd[89]: *** set a breakpoint in malloc_error_break to debug I've looked at vmmap, and while I get the gist of the output, I'm not sure what I should be looking for to see if the process's memory is fragmented. The -submap display shows plenty of small regions, but since I can't do a vmmap "right before I crash", I'm a little stumped... Can anyone point me at any guidelines, analysis tools, etc? 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 for the processes of interest and file a bug at <http://bugreport.apple.com/
with
the collected data, also including pre-existing crashlogs for the given process(es) and a system profile. You could also try to figure who are the most frequent callers to mmap in the given process. sudo dtrace -n 'syscall::mmap:entry / execname == "<insert name here>" / { @mstacks[ustack()] = count; }' and Ctrl-C after a bit. Once you file a bug report, Apple engineers may contact you via bugreporter and suggest/request further experiments. This email sent to eric.gouriou@pobox.com This email sent to site_archiver@lists.apple.com