On 14 Jul '08, at 4:12 PM, Shawn Erickson wrote:
It looks like you override release in your "Worker" object (based on
the back trace you posted). Are you thinking -[Worker release] is the
place to free resources? If so it isn't the right place. You want
-[Worker dealloc].
Right. -release just
On Mon, Jul 14, 2008 at 3:59 PM, James Trankelson <[EMAIL PROTECTED]> wrote:
> Thanks, Ken,
>
> I had a suspicion that's what was going on there, so I just added a
> few extra [Worker retain] messages before I sent the message to be
> handled. Still, the object gets released.
release != dealloc
I
Thanks, Ken,
I had a suspicion that's what was going on there, so I just added a
few extra [Worker retain] messages before I sent the message to be
handled. Still, the object gets released.
I have yet to find an explanation about any other reasons an object
might get released even after sending i
On Jul 14, 2008, at 5:25 PM, James Trankelson wrote:
The funny thing about my Worker class is that it's a singleton,
implementing the following method:
- (unsigned)retainCount
{
return UINT_MAX; //Never release
}
Are there other ways objects can get released if not by retainCount?
The i
Hi Jens,
You're suggesting that my Worker instance is being deallocated because
it's retain count is going to zero after the performSelector is
invoked, right?
The funny thing about my Worker class is that it's a singleton,
implementing the following method:
- (unsigned)retainCount
{
return
On 14 Jul '08, at 11:53 AM, James Trankelson wrote:
#0 0x0002606d in -[Worker release] at Worker.m:155
#1 0x94e8502a in __delayedPerformCleanup
#2 0x9390d92b in CFRunLoopTimerInvalidate
#3 0x9390e879 in CFRunLoopRunSpecific
#4 0x9390ecf8 in CFRunLoopRunInMode
#5 0x
