> On Jul 14, 2017, at 6:51 AM, Alex Zavatone <z...@mac.com> wrote: > >> On Jul 14, 2017, at 5:50 AM, Jeremy Hughes <moon.rab...@virginmedia.com> >> wrote: >> >>> On 12 Jul 2017, at 17:41, Jens Alfke <j...@mooseyard.com> wrote: >>> >>>> On Jul 12, 2017, at 9:34 AM, Jeremy Hughes <moon.rab...@virginmedia.com> >>>> wrote: >>>> >>>> // Prints "Why is childReference not nil?” >>> >>> There may still be a reference in the autorelease pool. Check >>> childReference again ‘later’, i.e. on the next user event or after a >>> timer/delayed-perform. >> >> Jens is correct. Here’s a modified version of the playground code that adds >> an autorelease pool: > > In the interest of getting more of a clue in regards to these items, is it > possible to examine the autorelease pools?
Xcode's memory graph tool can tell you if an object is pointed to by some autorelease pool. You can call _objc_autoreleasePoolPrint() in the debugger to dump the contents of the current thread's autorelease pool stack. You can set environment variable OBJC_PRINT_POOL_HIGHWATER=YES to record stack traces when a large autorelease pool is drained. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com