›

Erreurs cryptiques (pour moi)

berfisberfis Membre
dans API AppKit #1

Bonjour,


 


Après avoir téléchargé la dernière version de Xcode (Version 4.6.3 (4H1503)), je me retrouve avec ces erreurs que je n'arrive pas à  comprendre (elles n'empêchent pas le programme de fonctionner):




ibtoold(3536,0x10c08c000) malloc: *** auto malloc[3536]: error: GC operation on unregistered thread. Thread registered implicitly. Break on auto_zone_thread_registration_error() to debug.

et




/Applications/Xcode.app/Contents/Developer/usr/bin/ibtool emitted errors but did not return a nonzero exit code to indicate failure

ça semble être lié au fichier(s) xib mais je ne comprends pas l'opération GC alors que je suis en ARC...


 


Déjà  vu ce genre d'erreurs?


 


Merci.


Réponses

  • AliGatorAliGator Membre, Modérateur
    #2
    C'est pas ton code qui génère le message d'erreur, c'est ibtoold. Or ibtoold a été codé par Apple en utilisant le GC. D'où la mention de GC dans le message, que tu sois en ARC ou non, c'est un problème dans le code de ibtool.
  • berfisberfis Membre
    septembre 2013 modifié #3

    Donc... Bug Report ou pas?


     


    Cette application me fait des misères: chez moi elle fonctionne sur 10.8 (et même 10.9 mais bon...) et quand je l'installe au boulot sur un Mac 10.8, j'ai la console qui me sort des erreurs Core Data "Controller cannot be nil"... Je suis à  la frontière du bug, non? Enfin, elle est même franchie... Je sais, difficile de répondre sans voir le code...  <_<


  • AliGatorAliGator Membre, Modérateur
    #4
    Oui je dirai bugreport, avec le XIB problématique fourni en pièce-jointe du BugReport. De toute façon ça coûte rien
    (par contre détaille bien ton BugReport, de sorte qu'ils n'aient plus qu'à  ouvrir ton ZIP contenant ton exemple et constatent le problème, mieux c'est détaillé et plus tu leur fournis de quoi reproduire rapidement et plus tu as de chance qu'ils le traitent rapidement... même si la priorité aujourd'hui doit être sur Xcode5 et iOS7 chez eux !)
  • berfisberfis Membre
    #5

    Xcode 5 ne détecte pas de problème, NDA mise à  part...


  • AliGatorAliGator Membre, Modérateur
    #6
    Xcode5 est sorti officiellement le NDA est levé de fait.
  • berfisberfis Membre
    #7

    En effet. Je viens de voir ça.


  • berfisberfis Membre
    #8

    Bonsoir,


     


    Y a-t-il une bonne raison pour qu'une app qui fonctionne sans problème sur deux Mac chez moi (10.8) me sorte un "Controller cannot be nil" sur un iMac tout récent (sous 10.8) au boulot?


     


    L'erreur apparaà®t sur la console, l'app ne plante pas. Par contre, son fonctionnement ne correspond pas à  celui attendu (des objets qui refusent obstinément de se créer)...


     


    Là , je suis paumé.


  • AliGatorAliGator Membre, Modérateur
    #9
    Tu es sûr que tu as bien inclus tous des XIB et autres fichiers dans ton target ?

    Si sur tes deux macs où ça marche chez toi tu avais déjà  compilé avec ces fichiers et n'a jamais fait de Clean depuis, ça peut expliquer pourquoi ça marche sur ces macs (alors que ça ne devrait pas), et pas sur l'iMac tout récent. Si tu fais un "Clean" avant de compiler sur les deux Macs de chez toi qui marchent, est-ce que ça fonctionne toujours sans problème ou est-ce que du coup après ce Clean tu constates les mêmes problèmes que tu as vu sur le Mac du boulot ?

    Si oui cela ne vient donc pas de la machine mais de problèmes dans ton code (et si ça marchait jusqu'à  présent sur tes macs chez toi c'était donc un coup de bol si c'est ça)
  • berfisberfis Membre
    #10

    Merci pour la réponse.


     


    J'ai deux xib et ils sont inclus. Quant aux clean, j'en fais sans cesse car mes deux macs sont synchronisés avec un truc qui s'appelle Cubby et qui ne met pas à  jour (en passant) les modèles Core Data...


     


    Mon premier réflexe est toujours "l'erreur est dans mon code", à  tel point que depuis des années je ne dis plus "ça marche" mais "ça semble marcher". Cela dit, je suis face à  un bug particulièrement vicieux: Quand je dis que chez moi l'app semble fonctionner, il s'agit d'une version Release testée hors-Xcode (des fois que l'IDE "rattraperait le coup"). Les postes au travail vont d'un iMac ancien reboosté à  4Mo jusqu'à  l'iMac de 2013 à  8Mo. Chez moi j'ai un Mac Pro 2008 et le dernier MacBook. Ce n'est pas un problème de génération.


     


    Je vais donc transporter Xcode au boulot, et faire des tests in situ. Mais franchement, "Controller cannot be nil"... je préférerais une bonne plantée à  cette "erreur silencieuse"... Ou alors je poste mon projet ici et de bonnes âmes le testent chez elles...


     


    C'est vachement agaçant, surtout que pas mal de collègues attendent cette application: je revis le malaise de la "séance avec les clients" d'il y a pas mal d'années, quand la boà®te où je bossais devait régulièrement démontrer l'avance du produit...  B)


  • berfisberfis Membre
    septembre 2013 modifié #11

    OK, avec la nouvelle version Xcode, j'obtiens finalement cette erreur:



    
- (id)newObject {
    
id newObj = [super newObject];
    
NSLog(@newObj = %@",newObj);
    
...
    
return newObj;
    
}

    [super newObject] retourne NIL...


     


    Il s'agit d'une méthode d'une classe dérivée d'un NSArrayController gérant des NSManagedObjects (un cas trivial, donc). Dans Xcode 4.6, je n'avais pas d'erreur, dans Xcode 5.0 ça plante.


     


    Qu'est-ce que j'ai loupé? Surcharger newObject est une idée vue chez Hillegass, elle a toujours fonctionné jusqu'à  présent.


  • laudemalaudema Membre
    #12

    Es tu certain que super n'est pas lui déjà  égal à  nil ?


  • PyrohPyroh Membre
    #13

    Déjà  avec un NSArrayController il vaudrait pas mieux utiliser -(void)add:(id)sender ?


    Vérifie aussi que automaticalyPreparesContent retourne bien YES.


     


    Sinon poste ton projet on y regardera ;)


  • berfisberfis Membre
    septembre 2013 modifié #14

    C'est agaçant: même version Xcode, même version MacOS... deux comportements.


    laudema, de retour sur ma machine, j'obtiens:



    
2013-09-25 09:30:00.554 Demiurge[7254:303] super = NSKVONotifying_DeskController
    
2013-09-25 09:30:00.555 Demiurge[7254:303] newObj = <NSManagedObject: 0x10011cea0>
    

    
...

    Comportement attendu. Le DeskController existe, le NSArrayController (superclasse) est bien là , la création de l'objet est notifiée par KVO, et surtout l'objet retourné est conforme: un NSManagedObject dont les valeurs par défaut sont celles définies dans le model Core Data.


     


    Je nage dans le brouillard...


    @pyroh


    - Je pourrais surcharger add, mais en dernier recours il va appeler newObject.


    - Le contrôleur est bien en "Prepare Contents" (et pas Lazy Fetching).


     


    Je commence à  me demander si ce n'est pas au niveau d'une version de framework que quelque chose aurait changé. Peut-être ont-ils modifié newObject... Je n'ai rien trouvé dans la doc.


  • PyrohPyroh Membre
    #15

    Poste ton code quelque part qu'on teste alors c'est le plus simple ;)


  • FKDEVFKDEV Membre
    #16

    Un échec en amont,au niveau de la création du fichier CoreData par exemple ?


    Je pense qu'il y aurait un log, mais bon..


  • berfisberfis Membre
    #17

    Un embryon de piste? Au boulot, nous avons un serveur qui dessert une centaine de postes. Si je place mon App dans le dossier Applications de mon utilisateur, elle ne se lance pas. Si je la mets sur le bureau, elle se lance... et fonctionne correctement.


     


    Je me demande s'il ne s'agirait pas d'un problème de permissions: l'app ne pourrait pas créer le fichier préférences, ou un document scratch de Core Data ou autre chose encore --- si oui, comment régler ça?


  • AliGatorAliGator Membre, Modérateur
    #18
    Me dis pas que les documents que crée l'application sont mis dans le bundle de l'appli ou encore à  côté de l'application, et non dans un dossier dédié dans Application Support ou dans Preferences ou dans Caches (selon le type de fichier) comme préconisé par le FileSystem OSX ?
  • berfisberfis Membre
    #19

    Les documents de l'application sont enregistrés là  où l'utilisateur décide de les mettre: Longue vie au monde libre de MacOS!


     


    Le fichier Preferences est logé à  l'emplacement correct ( home/Library/Preferences/com.myCompany.myApp).


     


    L'application ne crée aucun autre fichier de manière explicite.


  • AliGatorAliGator Membre, Modérateur
    #20
    Que dit la Console.app ?
  • FKDEVFKDEV Membre
    #21
    Faudrait voir la liste des fichiers ouverts quand ça marche et quand ça marche pas... Avec lsof.
  • berfisberfis Membre
    #22

    Voyez ce que me sort la console


     


    Job failed to exec(3) for weird reason: 13


     


    Alors là , on se rapproche carrément d'un message Windows... "Weird"... ça ressemble à  un gag. Déjà  rencontré ça?

  • berfisberfis Membre
    #23

    J'ai d'abord pensé qu'il s'agissait d'un problème de permissions avec Core Data, mais j'ai installé une autre appli également CD qui fonctionne sans problème. "Contre ce genre de bugs, les dieux eux-mêmes luttent en vain".


Connectez-vous ou Inscrivez-vous pour répondre.