Re: How to debug *** -[NSCFString count]: unrecognized selector sent to instance
Re: How to debug *** -[NSCFString count]: unrecognized selector sent to instance
- Subject: Re: How to debug *** -[NSCFString count]: unrecognized selector sent to instance
- From: Marc Stibane <email@hidden>
- Date: Sat, 18 Apr 2009 04:57:44 +0200
Am 17.04.2009 um 16:25 schrieb Joar Wingfors:
On 17 apr 2009, at 07.16, Marc Stibane wrote:
Any tips how I could find out which object the system wanted to
send the message to in the first place?
Are there any debugging tools which e.g. mark (auto-)released
objects as dead, but do not free their memory so that new
allocations cannot take the same space? Then I could identify the
original object...
Yes, and that facility is known as NSZombieEnabled:
<http://www.google.com/search?q=site:developer.apple.com+NSZombieEnabled
>
Thanks.
I tried NSZombieEnabled - but that makes the object so dead you cannot
recognize anymore what it has been before. So I still don't know which
object I (auto-)release which the system still wants to access later
in the runloop.
I tried to follow this howto:
http://www.corbinstreehouse.com/blog/index.php/2007/10/instruments-on-leopard-how-to-debug-those-random-crashes-in-your-cocoa-app/
but couldn't get Instruments3 to launch my iPhoneSimulator app.
(when I add a "3", I mean the version which came with SDK 3.0 Beta 3
- when I add a 2 it means SDK 2.2.1)
So I launched Instruments2, Simulator2 and Xcode2, cleaned all, added
NSZombieEnabled, and tried to reproduce.... in vain. About 50 launches
later, it never crashed while running with Instruments.
I then just set NSZombieEnabled and started the normal Xcode debugger
- and it crashed on the first try! Thus I could see that
*** -[CFDictionary count]: message sent to deallocated instance
0x4a86fa0
there really is a release problem in my code.
However, the stack trace also showed the system routine
CFDictionaryGetCount to send the message, and that was directly called
from the runloop.
Since I use lots of NSDictionary objects in my iPhone views, and must
feed the server with all data to reach the point where the crash
happens, I cannot just comment out some code.
I am using an UISegmentedControl to let the user see (and download)
either 20, 50 or 100 items.
The crash only happens in the 3rd view, when I switch the shown search
results from 20 (default) to 50|100 and ask the server to load the
other 30|70 results, And it happens directly after the NSURLConnection
request, before the server even has a chance to decode the request,
let alone deliver any data...
So I guess it's a drawing update triggered by the UISegmentedControl,
which doesn't happen when loading the next/previous 20|50|100 items
(triggered by two UIButtons). The loading mechanism is absolutely the
same for the initial 20 items, and any next/previous items.
Hmm, since I don't know how many items the server could deliver, I
first set up the UISegmentedControl with only 1 item (20), and use
insertSegmentWithTitle:atIndex:animated to add a second segment for 50
and later a third for 100 items.
Looks like a perfect place for a [dictionary count], where the system
queries the control how many segments it has...
DANG. The UISegmentedControl was no property, but only an ivar...
Nope. It still crashes even after making the UISegmentedControl a
property (retain)...
It even still crashes after I comment out the
insertSegmentWithTitle:atIndex:animated: code line.
OK, at the top of the callstack is my limitSegmentPressed method.
#0 0x00003a3c in -[ResultViewController limitSegmentPressed:] at
ResultViewController.m:336
#1 0x30a551e9 in -[UIApplication sendAction:to:from:forEvent:]
#2 0x30ab4bce in -[UIControl sendAction:to:forEvent:]
#3 0x30ab5096 in -[UIControl(Internal) _sendActionsForEvents:withEvent:]
#4 0x30ab4c3f in -[UIControl sendActionsForControlEvents:]
#5 0x30ae1511 in -[UISegmentedControl setSelectedSegmentIndex:]
#6 0x30a6d7ab in -[UIWindow sendEvent:]
#7 0x30a5d0ea in -[UIApplication sendEvent:]
#8 0x30a5c50d in _UIApplicationHandleEvent
#9 0x31550396 in SendEvent
#10 0x31552700 in PurpleEventTimerCallBack
#11 0x928f85f5 in CFRunLoopRunSpecific
#12 0x928f8cd8 in CFRunLoopRunInMode
#13 0x31550bac in GSEventRunModal
#14 0x31550c71 in GSEventRun
#15 0x30a54fa3 in -[UIApplication _run]
#16 0x30a60187 in UIApplicationMain
#17 0x00018425 in main at main.m:15
Instead of clicking "Continue", I can just hit "Step Out" 8 times until
#8 _UIApplicationHandleEvent
is to be leaved, and that'll call CFDictionaryGetCount and crash...
*** -[CFDictionary count]: message sent to deallocated instance
0x59c820
Absolutely reproducable now - that is, as long as I don't run it with
Instuments:ObjectAllocations - then it doesn't crash...
Gee, I need some sleep...
--
In a world without walls and fences,
who needs windows and gates?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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