On Jan 4, 2010, at 1:39 PM, jonat...@mugginsoft.com wrote: > How can a multiple stack root occur? > Is this just saying that the same object is referenced by multiple stack > allocated pointers at the time that the sample was taken?
That is correct; the object may be referenced by multiple local variables [on the stack]. Note that since the stack is scanned conservatively, you may be seeing stale references -- references that have gone out of scope. > Presumably a stack root cannot be the source of any persistent leak as once > the frame is gone so is the root. One would like to believe that, but it isn't always the case. On AMD64, the ABI specifies that there is a "red zone" of 128 bytes allocated just below the current stack pointer that can be used as scratch space. Thus, the collector has to also scan the red zone conservatively. However, the red zone will often contain whatever local variables -- including arguments (which are an awful lot like local variables, really) -- that were written there when the current frame called a function somewhere, pushing a frame below. Hence the need for objc_clear_stack(). Among other things, it clears the red zone. (Don't let the details scare you -- as long as you are using the recommended run loop / grand central dispatch mechanisms for looping and waiting, clearing the stack is handled automatically. That is, very very few developers will ever run into a need to deal with this directly). > Sorry if this is dumb question. I am struggling to comprehend just what the > ObjectGraph tool is telling me. > Docs seem MIA for this tool (or maybe it's me that's MIA). File a bug, please! > Most of my rooted objects are statically allocated singletons. ObjectGraph > correctly identifies them as single roots. Good. Note that you can also use gdb to perform the same analysis. In any GC'd program, 'info gc-roots <addr>' and 'info gc-referers <addr>' can be used to interrogate the connectivity of the object at <addr>. b.bum _______________________________________________ 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
