Re: Problem tracking crash in iOS
Re: Problem tracking crash in iOS
- Subject: Re: Problem tracking crash in iOS
- From: Doug Hill <email@hidden>
- Date: Wed, 16 Nov 2011 15:59:41 -0800
On Nov 16, 2011, at 3:45 PM, Laurent Daudelin wrote:
> Yeah, except the project uses ARC which prevents using dealloc…
With ARC enabled, you can still define a dealloc method for your object and it will get called when the ref-count of the object goes to 0. Apple's ARC documentation discourages writing dealloc methods but doesn't forbid it. ARC only stops you from calling release directly. So, if the object doesn't have a dealloc, you can define one for the purposes of the breakpoint.
> This is an interesting problem, though. If I turn on NSZombieEnabled and if the original observer is deallocated, shouldn't an NSZombie takes its place and shouldn't the NSZombie raises an exception when it receives the message that was registered with the notification? Why isn't it happening?
You are correct, if the issue is that messages are sent to a destructed object with NSZombie enabled, it should throw an exception AND print some text to the console letting you know info about the exception. You might not see the the exception if there was code to suppress it e.g. a @try/@catch block. Debugging these things is tricky so it's best to try many things and not to assume too much. For example, your memory footprint will change with NSZombie enabled. So how objects are laid out in memory can change leading to different behavior with respect to object allocation and reuse of destructed objects.
Memory corruption bugs are usually very difficult to debug and don't generally have one solution for al cases. Verify your code, collect as much data about the problem, hone in on a solution.
Doug Hill
Schematic Labs, Inc.
http://soundtracking.com/
> On Nov 16, 2011, at 15:19, Doug Hill wrote:
>
>> If you know what the observer object in question is, you can put a breakpoint in it's dealloc to see if it's in fact being deallocated.
>>
>> Good luck!
>>
>> Doug Hill
>>
>> On Nov 16, 2011, at 3:10 PM, Laurent Daudelin wrote:
>>
>>> Thanks, Doug, I had started looking at this but will definitely put all my attention on why the original observer wouldn't be there to receive the notification, although, so far, I can't see how it would be deallocated.
>>>
>>> -Laurent.
>>>
>>> On Nov 16, 2011, at 14:57, Doug Hill wrote:
>>>
>>>> When you see notifications being sent to random objects, it usually means the original registered observer object was deallocated without removing the observer for the notification. The notification is then sent to a random object that now resides in the reused space formerly occupied by the original observer. I would check if you're removing your observers first before getting too crazy with debugging.
>>>>
>>>> Doug Hill
>>>>
>>>> On Nov 16, 2011, at 2:23 PM, Laurent Daudelin wrote:
>>>>
>>>>> I'm working on an app with a bug that is reproducible each time. Some object is trashed and the NSNotificationCenter tries to send a notification to an object that doesn't respond to that selector. I turned on NSZombieEnabled and a bunch of other settings for my debug session but when I turn on NSZombieEnabled, the crash doesn't occur and the app keeps running.
>>>>>
>>>>> How can I find out which object is wrongly deallocated? And no, I didn't write the app...
>>>>>
>>>>> Thanks in advance!
>>>>>
>>>>> -Laurent.
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden