« June 2010 | Main | August 2010 »

July 2010 Archives

July 13, 2010

(Buggy ?) Instruments tries to trick me

Here is a small Xcode test project that will successfully run standalone or in the debugger, but will crash when run with Instruments.

(In Xcode use the "Run" menu, choose "Run with Performance Tool" and select "Leaks"). What this project is doing, is overloading a category in Foundation with a method, that is itself stored in a Framework. In a condensed form it looks like this.

SomethingBadHappened.zip
// defined in a framework 
@implementation NSObject( NSUnpublishedEOFDebug)

- (void) addObject:(id) obj 
toBothSidesOfRelationshipWithKey:(NSString *) key
{
   NSLog( @"%@ %s: %@ %@", 
          self, __PRETTY_FUNCTION__, obj, key);
   NSLog( @"Denied!");
}

@end
and 
// defined in a tool, linking to the framework
int main (int argc, const char * argv[]) 
{
   [@"foo" addObject:@"bar" 
toBothSidesOfRelationshipWithKey:@"baz"];
}
And this is what you will see, if you are using Xcode 3.2.2.

Normal run
+[NSObject( NSUnpublishedEOFDebug) load]
foo -[NSObject(NSUnpublishedEOFDebug) addObject:toBothSidesOfRelationshipWithKey:]: bar baz
Denied!
Instruments run
+[NSObject( NSUnpublishedEOFDebug) load]
*** WARNING: -[NSObject(NSKeyValueCoding) takeValue:forKey:] is deprecated. It will be removed in a future release and should no longer be used.
*** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<NSCFString 0x2024> takeValue:forKey:]: attempt to assign value to unknown key: 'baz'.
This class does not have an instance variable of the name baz or _baz, nor a method of the name setBaz, or _setBaz'
*** Call stack at first throw:
(
0 CoreFoundation 0x9440abba __raiseError + 410
1 libobjc.A.dylib 0x94f4d509 objc_exception_throw + 56
2 CoreFoundation 0x944559f1 -[NSException raise] + 17
3 Foundation 0x9833a179 _raiseKeyValueException + 234
4 SomethingBadHappened 0x00001ef7 main + 125
5 SomethingBadHappened 0x00001e71 start + 53
)
<End of Run>

Some Thoughts

  • Does not crash with Shark
  • Yes, Foundation still has some old EOF methods contained in a category called NSUnpublishedEOF.
  • If the category is not part of the test framework, but part of the tool. There is no such problem.
  • Since, the test framework is dependent on Foundation, Foundation must be loaded first.
  • It's as if by a accident Foundation was loaded again, and it's categories override the test framework categories.

Posted by Nat! on July 13, 2010 12:52 AM | | Comments (0)

Betcha can't debug that

Along the lines of those guitar videos here is an Xcode Project, that crashes in the Xcode debugger but not stand alone. I bet you can't debug that!

The expected output of the debugger is:

Running...
memory_pressure: 0memory_pressure: 02010-07-13 21:51:44.114 MoreTroubleInXcode[13281:a0f] I don't blame you.
Program received signal: "SIGABRT".
sharedlibrary apply-load-rules all
Cannot access memory at address 0x0
Cannot access memory at address 0x0
(gdb)

Continue reading "Betcha can't debug that" »

Posted by Nat! on July 13, 2010 8:43 PM | | Comments (0)

July 14, 2010

EXC_BAD_ACCESS and no stack trace == more quality time lost in Xcode

DISCLAIMER: THIS IS FOR i386 ONLY

And as things are wont to do, Xcode debugging just went from bad to worse for me. To figure out some other problems (see previous posts) I enabled some debug code, which led to this crasher in middle of nowhere^h^h^h^h^h^h^hobjc_msgSend. There is this tendency of debug code to create more bugs and henceforth more debug code, but I disgress...

With no clue in the console log and no stack trace (see picture) I was stumped.

Obviously the crash occurs at 0x986ceed7, where you see the red instruction pointer arrow.

Recovering the Stacktrace

You can help Xcode along a little ways to display the correct stack trace, and only god and apple know, why it can't do this on its own, but I guess syntax coloring is way more important...

Move the instruction pointer to a ret instruction. In the screenshot the address of a known ret instruction is marked green. If you see a different hexadecimal number in your disassembly there, by all means use that. Now go into the gdb debugger console to recover the stack trace: 

(gdb) set $eip = 0x986cef35
(gdb) stepi
(gdb) where
#0  0x00000000 in ?? ()
#1  0x9842e5a4 in _NSDescriptionWithLocaleFunc ()
#2  0x92b04322 in _CFStringAppendFormatAndArgumentsAux ()
#3  0x92b036a9 in _CFStringCreateWithFormatAndArgumentsAux ()
#4  0x92babf2e in _CFLogvEx ()
#5  0x984bf7e8 in NSLogv ()
#6  0x984bf757 in NSLog ()
...

Voilà! Or Viola as it's commonly misspelled.

Continue reading "EXC_BAD_ACCESS and no stack trace == more quality time lost in Xcode" »

Posted by Nat! on July 14, 2010 5:25 PM | | Comments (1)

Search


About July 2010

This page contains all entries posted to Nat!'s Web Journal in July 2010. They are listed from oldest to newest.

June 2010 is the previous archive.

August 2010 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Subscribe to this blog's feed
[What is this?]
Powered by
Movable Type 4.34-en
MoreTroubleInXcode.zip