On 7 Jun 2013, at 6:05 AM, Jonathan Taylor <[email protected]>
wrote:
> [Greg Parker:]
>> "The Allocations instrument should report objects with pending autoreleases
>> as ordinary live objects"
>
> Do you happen to know if that's true of Allocations on 10.6? Is that
> definitely true for objects that have actually passed out of scope, and it
> would therefore be forbidden to re-retain them (if you know what I mean), but
> which haven't actually been freed "behind the scenes"?
Greg Parker's lightest word would annihilate even my deepest thoughts, but this
is my no-inside-information understanding of the semantics of the autorelease
pool:
It's just a broker with no insight into the state of the objects it holds. It
does a retain when an object is presented, counts the retains it does, and does
N releases when the pool is drained. Nothing special, and no way to decide
whether all of the ownership count relates to what may be a stack of
autorelease pools.
There are optimizations — ARC includes a lot of them — but people have relied
on those semantics for decades, and there's not much scope to change them. It
has to act-as-if.
If you already can pick out the object you're interested in in the Allocations
history, and you turn retain tracking on, you can study the retain count and
see how many times the object has been autoreleased. But Instruments has no way
of flagging whether a retain pattern is other than what you expect/intend.
The out-of-scope compile-time condition you suggest would be very hard to
detect reliably. Clang may be insightful enough that it could instrument the
object code to give the Allocations instrument clues, but that would be the
next OS at the earliest, and doesn't help you on Snow Leopard.
I have no clue about your root problem, which is bizarre according to what
you've told us. My approach to such things is to blunder around until something
suggests itself. It smells like you're doing a lot of processing with temporary
objects, in a loop, without bracketing the loop body in @autoreleasepool{}, but
I remember you saying you're not.
[I remember vaguely that CG operates its own heap for image buffers, which is
what your error message complains about. I dealt with it a long time ago, and I
may be misremembering. What does the VM Tracker instrument say?]
— F
--
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
