Hi Ken Thanks for this - most illuminating !
I have been checking out code around the crash point - it was easy to isolate - and the exception may well have emanated from my trying to do a deep copy of a class that does not have initWithCoder / encodeWithCoder methods. I seem to remember that with past versions of the compiler, performing this piece of nonsense produced a warning from the compiler. It was so long ago now though ….. Regards Peter On 24 Dec 2011, at 13:20, Ken Thomases wrote: > On Dec 24, 2011, at 6:11 AM, Peter Hudson wrote: > >> I have been making a few ( trivial ) changes to some code and when the app >> runs it grinds to a halt with an >> Objective-c exception and the next to last item on my stack is >> >> __PRETTY_FUNCTION__.219635 >> >> ( the top of the stack being obj_msgSend ) >> >> Anybody have any ideas on this one. I can't get the debugger to show me any >> detail about PRETTY_FUNCTION at all. > > That symbol is for a string, which is the name of the function. It's not a > function itself. > > In C code, you can reference __FUNCTION__, __PRETTY_FUNCTION__, and __func__ > in cases (usually debugging statements) where you need the name of the > function. The compiler generates a string variable and the symbol for that > variable is something like the above. > > Since it's not the name of a function, it shouldn't be on the stack. Some > possible reasons that it would appear in a stack trace include: > > * objc_msgSend can confuse debuggers and strack tracers because it doesn't > manipulate the stack pointer or frame pointer in the usual way. > > * Certain symbols have been stripped from your program and its libraries. > The function that's actually on the stack no longer has its symbol, so its > address is correlated with an arbitrary different symbol that comes earlier. > This strikes me as unlikely. > > * The program generates new code at runtime and has called such a function. > That function would have no symbol and, again, its address was just > correlated with the nearest prior symbol. > > * The stack has been corrupted, so the stack tracer is getting bogus results. > > I'd recommend enabling zombies, perhaps using the Zombies template for > Instruments. Also, see if Xcode's static analyzer finds any problems with > your code. If neither of those turns up anything, you can sprinkle printfs > or NSLog calls through the suspect code to figure out where the crash is > happening. > > Good luck. > > Regards, > Ken > _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
