Obtention d'un message de débogueur étrange: Échec de l'assertion: (cls), function getName: qu'est-ce que c'est?

Question

Depuis la mise à niveau de Xcode 3.2.3 vers 3.2.4 et iOS 4.0.1 vers iOS 4.1 SDK, lorsque je définis un point d'arrêt dans mon code et mon pas, à chaque étape, le débogueur crache un ou plusieurs de cette ligne:

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

Il ne se produit pas sur une ligne spécifique ou pour une des instructions spécifiques. J'ai quelques points d'arrêt dans mon code et chaque fois que j'en touche un, le débogueur commence à cracher ces messages. Cela ne semble pas avoir d'effet négatif car le programme fonctionne correctement. C'est juste très ennuyeux de récupérer les informations dans la console quand il y a des dizaines de ces lignes. Je suis sûr qu'ils ne sont pas affichés pour rien mais je n'ai pas trouvé quel pourrait être le problème et quelle instruction pourrait le causer. Si je ne frappe pas un point d'arrêt, alors je ne vois aucune de ces lignes. J'ai nettoyé et reconstruit mon projet plusieurs fois en vain.

Est-ce que quelqu'un a une idée de ce que c'est?

Answer 1

J'ai exactement le même problème. Je sais que ce n'est pas la réponse complète mais voici ce que j'ai pu trouver.

La getName de fonction correspondante ressemble à ceci:

/*********************************************************************** 
* 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; 
    } 
} 

Alors gdb se plaint que l'assertion d'assertion (CCRS) échoue. Ce qui signifie que getName obtient en quelque sorte un pointeur NULL en tant qu'argument.

Ce qui est plutôt drôle, où pourrions-nous demander le nom d'une classe NULL?

Hope this helps ...

Answer 2

J'ai aussi le même problème; Je n'ai pas de solution mais je suis capable de contourner cela. En bref, je vous suggère d'ajouter plus de points d'arrêt ...

J'ai remarqué dans la pile d'appels que c'est en fait le débogueur qui se comporte mal. La fonction gdb_class_getClass appelle getName, supposé que cela passe NULL au lieu de (par exemple) MyClass. Le code que j'essaye de déboguer est une méthode de MyClass. Donc, en pensant que le débogueur a un problème avec MyClass, je place un point d'arrêt sur une ligne en dehors de tout code de MyClass (c'est-à-dire la ligne qui appelle la méthode sur MyClass) et je clique sur continuer quand le programme casse. Cela semble résoudre le problème dans mon cas. (Notez que reprise automatique ne fonctionne pas.)

Pour être clair:

//Set breakpoint here 
[myClassInstance buggyMethod]; 

Mon buggyMethod est en fait dans un autre fichier:

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

espoir qui aide.

Answer 3

J'ai un problème similaire, mais le mien est avec la création d'une vue personnalisée avec Core Text. Dès que drawRect de mon point de vue appelle la ligne

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

Il bloque l'application, que ce soit dans le simulateur ou sur l'appareil. Bizarrement, je peux rectifier cela en allouant un autre composant de texte UIKit dans la méthode viewDidLoad de View Controller ... Je n'ai même pas besoin de l'ajouter en sous-vue. C'est comme si elle avait besoin d'éléments de texte communs chargés avant que Core Text puisse charger dans les polices.

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

Bizarre.

Answer 4

J'ai couru dans ceci - et voici la raison pour laquelle la mienne est arrivée: j'avais utilisé +localizedStringFromDate:dateStyle:timeStyle: dans mon code. Fonctionne bien sur l'iPhone, mais ce n'est pas disponible pré-4.0 SDK, donc il tousse sur l'iPad. Vérifiez si vous appelez une routine qui n'est plus disponible dans le SDK ou disponible uniquement dans les versions ultérieures. Franchement, je ne peux pas attendre pour 4.1 sur l'iPad!

-Owen

Answer 5

Je suis aussi avoir ce problème, dans une application iPad écrit en Xcode 3.2.4 en utilisant le SDK iOS 3.2, maintenant dans Xcode 3.2.5 débogué à l'aide du SDK 4.2, mais seulement quand j'ai mis le simulateur à la cible de déploiement iOS 3.2 (donc je peux courir dans le simulateur 3.2). Chaque arrêt à un point d'arrêt dans le débogueur, je reçois cet assertion répété huit fois. Aller seul sur une ligne en obtient deux de plus. Ce que je ne peux pas comprendre, c'est que je n'ai pas ajouté de code au projet depuis que je l'ai utilisé pour la dernière fois dans Xcode 3.2.4 et iOS SDK 3.2, donc je ne peux pas ajouter d'appels qui n'étaient pas présents dans ce SDK ou sinon il n'aurait pas compilé. Jusqu'à ce que quelqu'un trouve une réponse à cela, je pense que la seule solution de contournement (afin que je puisse continuer à déboguer mon code dans un environnement 3.2) est de réinstaller Xcode 3.2.4 et d'utiliser le SDK 3.2 et le simulateur.

Answer 6

J'ai eu ce problème lorsque je courais sur simulateur "simulateur de l'iPad 3.2". Ce problème a disparu quand j'ai basculé le simulateur sur "simulateur iPad 4.3"