debugging runaway allocations under gc
debugging runaway allocations under gc
- Subject: debugging runaway allocations under gc
- From: "email@hidden" <email@hidden>
- Date: Mon, 7 Jul 2008 10:35:30 -0700
We have an "out of memory" crasher in a gc app that we are trying
debug, but I'm having a bit of difficulty bringing the correct tools
to bear on the problem.
I suspect that either we have some kind of runaway loop that's
allocating us into oblivion, or we're outrunning the collector (I
suspect the latter because the crash is never in exactly the same
place, and no long processes are in progress). I have a reproducible
case where we basically hammer the app with the same command over and
over again (via script_, and memory usage does indeed increase
(albeit slowly) over time, but at some stage it reaches a "tipping
point" where the allocation just runs away quickly, and in the course
of a couple seconds consumes all available resources and crashes.
I tried running "heap" to see what was actually allocated and where,
but after two hours pegging one of my four cores, heap is still
churning. I tried using MallocDebug, but it's not compatible with gc
(apparently). I tried using ObjectAlloc in instruments, but it
generates so much data that instruments itself chokes on all the data
and starts the machine churning (I was hoping for a windowed time
facility as in Shark). I even tried conditional breakpoints on
malloc to try to catch large allocations, but I don't think I've got
the syntax of the condition right (I did manage to get it working
using a debugger command for the breakpoint, but after a while it
stops working).
So now I'm looking for pointers on where I should be poking to try to
get more data. What are good strategies to try and see if I'm
outrunning the collector? Can I detect a low resource situation (for
debug purposes only) and wait it out a bit and see if the collector
catches up? (how?) What's the best way to find large malloc
allocations that doesn't involve instruments collapsing under the
load of data? (it can take 10 minutes or more to reach the failure
point). All pointers appreciated.
_______________________________________________
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