Getting strange debugger message: Assertion failed: (cls), function getName: what is this?

Question

Since I upgraded from Xcode 3.2.3 to 3.2.4 and iOS 4.0.1 to iOS 4.1 SDK, when I set a breakpoint in my code and single-step over instructions, at each step, the debugger will spit one or more of that line:

Assertion failed: (cls), function getName, file /SourceCache/objc4_Sim/objc4-427.1.1/runtime/objc-runtime-new.m, line 3939

It doesn't happen on a specific line or for a specific instructions. I have a few breakpoints in my code and each time I hit one of those, the debugger starts spewing those messages. It doesn't seem to have any detrimental effect as the program works correctly. It's just very annoying to retrieve the information in the console when there are tens of those lines. I'm sure they're not displayed for nothing but I haven't found what the problem might be and what instruction might cause it. If I don't hit a breakpoint, then I don't see any of those lines. I did clean and rebuild my project multiple times to no avail.

Does anybody have any idea what this is?

Answer 1

I have exactly the same issue. I know it's not the complete answer but here's what I could find.

The relevant function getName looks like this:

/***********************************************************************
* getName
* fixme
* Locking: runtimeLock must be held by the caller
**********************************************************************/
static const char *
getName(struct class_t *cls)
{
    // fixme hack rwlock_assert_writing(&runtimeLock);
    assert(cls);

    if (isRealized(cls)) {
        return cls->data->ro->name;
    } else {
        return ((const struct class_ro_t *)cls->data)->name;
    }
}

So gdb is complaining that the assertion assert(cls) is failing. Which means that getName somehow gets a NULL pointer as an argument.

Which is kinda funny, where could we be asking for the name of a NULL class?

Hope this helps...

Answer 2

I also have the same problem; I don't have a solution but I'm able to work around it. In short, I suggest you add more breakpoints...

I noticed in the call stack that it's actually the debugger that is misbehaving. The function gdb_class_getClass calls getName, presumedly this is passing NULL instead of (say) MyClass. The code that I'm trying to debug is a method of MyClass. So, thinking that the debugger has a problem with MyClass, I set a breakpoint at a line outside of any code of MyClass (ie the line that calls the method on MyClass) and hit continue when the program breaks. This seems to resolve the problem in my case. (Note that auto-continue doesn't work.)

To be clear:

//Set breakpoint here
[myClassInstance buggyMethod];

My buggyMethod is actually in another file:

...
-(void)buggyMethod {
    //This is where I set my 'real' breakpoint

Hope that helps.

Answer 3

I'm having a similar problem, but mine is with creating a custom view with Core Text in it. As soon as my view's drawRect calls the line

CTFontRef titleFont = CTFontCreateWithName(CFSTR("Baskerville"), 40.0f, NULL); 

It hangs the app, whether in the simulator or on the device. Bizarrely, I can rectify this by alloc-initing another UIKit text component in the View Controller's viewDidLoad method... I don't even have to add it as a subview. It's like it needs some common text elements loaded before Core Text can load in fonts.

- (void)viewDidLoad
{
    [super viewDidLoad];
    UILabel *l = [[UILabel alloc] initWithFrame:CGRectMake(0, 0, 0, 0)];        
}

Weird.

Answer 4

I ran into this - and here's the reason mine happened: I had used +localizedStringFromDate:dateStyle:timeStyle: in my code. Worked fine on the iPhone, but it's not available pre-4.0 SDK, so it coughed on the iPad. See if you're calling some routine that's either no longer available in the SDK, or available only in later versions. Frankly, I can't wait for 4.1 on the iPad!

-Owen