How to debug *** -[NSCFString count]: unrecognized selector sent to instance
How to debug *** -[NSCFString count]: unrecognized selector sent to instance
- Subject: How to debug *** -[NSCFString count]: unrecognized selector sent to instance
- From: Marc Stibane <email@hidden>
- Date: Fri, 17 Apr 2009 16:16:10 +0200
I get hard to reproduce crashes, both in the simulator and native on
the iPhone. Adding some NSLogs sometimes make the crashes go away,
adding more (totally unrelated) code make them come back.
The crashlog shows that it always happens in the run loop - on the
callstack is only my "main" routine, nothing else from my own code,
but system routines:
__TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION__
dyld_stub_writev$UNIX2003
CFRunLoopRunSpecific
CFRunLoopRunInMode
GSEventRunModal
GSEventRun
Since it (so I thought) didn't happen the day before I took my
snapshot and the current version and tried to work in both directions
(adding code to the old snapshot and deleting code from the current
version) to find the culprit. However, after adding some absolutely
harmless lines the crash occured also in the snapshot...
So it seems the error is not in the new modifications, but buried deep
in my code, and just now shows up as a side effect.
*** -[NSCFString count]: unrecognized selector sent to instance
0x590740 (the hex address changes every time, so I cannot add a
watchpoint)
In the Debugger Console, typing "po 0x590740" usually shows an
autoreleased NSString object which my code used shortly before it
returned to the run loop.
I guess the system wants to access some (older) object from my code
which somehow got (auto-)released, and by chance the newer object (my
NSString) happened to be allocated at the same memory location and
thus, though already autoreleased and definitely no longer needed,
gets the first object's method selector it doesn't understand.
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...
--
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