›

[Résolu] Retrouver une ligne d'exception - Xcode

Am_MeAm_Me Membre
octobre 2014 modifié dans API UIKit #1

Voilà  ma question est simple :


 


Est-il possible sans breakpoint de pouvoir retrouver une ligne qui a générer une exception :


 


J'ai en ce moment une exception qui apparait qq fois voir pas mal de fois sur insertObject et objectAtIndex




*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'

*** First throw call stack:

(

0   CoreFoundation                      0x000000010d48f3f5 __exceptionPreprocess + 165

1   libobjc.A.dylib                     0x000000010d128bb7 objc_exception_throw + 45

2   CoreFoundation                      0x000000010d35dd0a -[__NSArrayM insertObject:atIndex:] + 954

3   SpySeries                           0x000000010a5b1954 -[ViewController initAndSortFavorites:completion:] + 3092

4   SpySeries                           0x000000010a5ae925 -[ViewController viewDidLoad] + 1733

5   UIKit                               0x000000010bb0b190 -[UIViewController loadViewIfRequired] + 738

6   UIKit                               0x000000010bb0b38e -[UIViewController view] + 27

7   SpySeries                           0x000000010a62db79 -[RESideMenu viewDidLoad] + 3945

8   UIKit                               0x000000010bb0b190 -[UIViewController loadViewIfRequired] + 738

9   UIKit                               0x000000010bb0b38e -[UIViewController view] + 27

10  UIKit                               0x000000010ba2adb9 -[UIWindow addRootViewControllerViewIfPossible] + 58

11  UIKit                               0x000000010ba2b152 -[UIWindow _setHidden:forced:] + 276

12  UIKit                               0x000000010ba3765c -[UIWindow makeKeyAndVisible] + 42

13  UIKit                               0x000000010b9e2191 -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 2628

14  UIKit                               0x000000010b9e4e5c -[UIApplication _runWithMainScene:transitionContext:completion:] + 1350

15  UIKit                               0x000000010b9e3d22 -[UIApplication workspaceDidEndTransaction:] + 179

16  FrontBoardServices                  0x00000001121952a3 __31-[FBSSerialQueue performAsync:]_block_invoke + 16

17  CoreFoundation                      0x000000010d3c4abc __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12

18  CoreFoundation                      0x000000010d3ba805 __CFRunLoopDoBlocks + 341

19  CoreFoundation                      0x000000010d3b9fc3 __CFRunLoopRun + 851

20  CoreFoundation                      0x000000010d3b9a06 CFRunLoopRunSpecific + 470

21  UIKit                               0x000000010b9e3799 -[UIApplication _run] + 413

22  UIKit                               0x000000010b9e6550 UIApplicationMain + 1282

23  SpySeries                           0x000000010a5dbbf3 main + 115

24  libdyld.dylib                       0x000000010e063145 start + 1

25  ???                                 0x0000000000000001 0x0 + 1

)

libc++abi.dylib: terminating with uncaught exception of type NSException

Je me tape cette exception et je suis embêté j'ai beaucoup de classe etc ... mais j'aimerai retrouver la ligne en question est-ce possible docteur ?


Réponses

  • CéroceCéroce Membre, Modérateur
    #2

    Pourquoi sans breakpoint ? C'est quand même le plus simple.


  • AliGatorAliGator Membre, Modérateur
    octobre 2014 modifié #3
    Si ton device est branché quand ton crash arrive, je plussoie la remarque de Céroce, il faut le faire avec breakpoint, c'est fait pour et bien plus adapté.

    Après, si le crash survient chez des utilisateurs par exemple en tout cas quand le device n'est pas branché à  ton mac et à  Xcode, et que tu récupères le CrashLog qu'après coup, bah il suffit de symboliser ton CrashLog.

    Normalement si tu le charges dans Xcode, Xcode symbolise le crashlog tout seul.

    Evidemment, il faut avoir gardé le dSYM qui a été généré avec l'IPA (chaque recompilation génère un dSYM différent). C'est pour cela que pour les livraisons, on passe par "Archive" et pas "Build", pour archiver à  la fois l'IPA (prêt à  être envoyé pour une livraison sur l'AppStore ou en OTA) et son dSYM (pour pouvoir symboliser les éventuels crashlogs et ainsi retrouver la correspondance adresses mémoires <-> méthodes et lignes)
  • samirsamir Membre
    #4

    Comme les autres il faut mettre des breakpoints. 


     


    Sinon vu ta capture d'écran, l'exception est générée à  l'exécution de la méthode : initAndSortFavorites qui appelé la méthode insertObject...  Donc c'est plus facile de retrouver la ligne qui foire sauf si ta méthode fait des centaines de lignes :)

  • SmySmy Membre
    #5


    Normalement si tu le charges dans Xcode, Xcode symbolise le crashlog tout seul.




     


    Dans la vraie vie, c'est toujours plus compliqué.


     


    Sur certains projets, j'ai du jouer à  la main avec symbolicatecrash...

  • Am_MeAm_Me Membre
    octobre 2014 modifié #6


    Comme les autres il faut mettre des breakpoints. 


     


    Sinon vu ta capture d'écran, l'exception est générée à  l'exécution de la méthode : initAndSortFavorites qui appelé la méthode insertObject...  Donc c'est plus facile de retrouver la ligne qui foire sauf si ta méthode fait des centaines de lignes :)




     


    D'accord parceque moi je n'arrivais pas à  analyser le log. Donc c'est cette fonction qui a un problème. Merci


    _____


     


    Ok @toutlemonde mais bon mettre 50 breakpoint et surtout parfois c'est dans le cellforrow et attendre 10 plombes c'est un peu lassant à  la fin. Ensuite le crash intervient sur mon simulateur, mon iDevice semble être immunisé lol pour le moment du coup j'essaie de corriger le problème


     


     


    MAJ : Du coup merci @samir j'ai compris d'ou venait mon problème "rare" ou plutôt introuvable. 


    Mais je suis d'accord avec vous les breakpoints c'est bien


    Je prend exemple sur eclipse qui permet lors d'une custom Exception ou une Exception système de nous envoyer vers une zone de code problématique. 


  • CéroceCéroce Membre, Modérateur
    #7

    Onglet Breakpoints


    +


    Add Exception Breakpoint


  • Am_MeAm_Me Membre
    #8

    Smy Ok pour symbolicatecrash je verrais ça plus tard ;) mais merci pour l'info


  • Am_MeAm_Me Membre
    #9

    Céroce le truc que tu me donne au dessus c'est pour quoi faire exactement ? Pareil qu'Eclipse ?


     


    Et j'ai Create et pas de Add ==> je suppose que ça ne change rien


  • AliGatorAliGator Membre, Modérateur
    octobre 2014 modifié #10

    D'accord parceque moi je n'arrivais pas à  analyser le log. Donc c'est cette fonction qui a un problème. Merci

    Heu c'est un peu inquiétant quand même... Le crashlog est quand même assez facile à  lire, tu as la callstack à  droite, c'est assez clair les méthodes qui ont été appellées successivement, je vois pas comment tu pourrais les louper. La seule chose qui te manque c'est les numéros de ligne.
     

    Ok @toutlemonde mais bon mettre 50 breakpoint et surtout parfois c'est dans le cellforrow et attendre 10 plombes c'est un peu lassant à  la fin.
    [...]
    Je prend exemple sur eclipse qui permet lors d'une custom Exception ou une Exception système de nous envoyer vers une zone de code problématique.

    Onglet Breakpoints -> Bouton "+" tout en bas -> "Add Exception breakpoint" (on en a déjà  parlé dans plusieurs posts ;))
  • colas_colas_ Membre
    #11

    Le symbolic breakpoint est génial.


     


    Si tu as un bug, xcode va automatiquement s'arrêter à  la ligne où il y a un problème !


  • Am_MeAm_Me Membre
    #12


    Heu c'est un peu inquiétant quand même... Le crashlog est quand même assez facile à  lire, tu as la callstack à  droite, c'est assez clair les méthodes qui ont été appellées successivement, je vois pas comment tu pourrais les louper. La seule chose qui te manque c'est les numéros de ligne.

     




     


    Bah il y a pas qu'une seul fonction dans le log disons que je ne savais pas laquel prendre bref.


     


     


     




    Le symbolic breakpoint est génial.


     


    Si tu as un bug, xcode va automatiquement s'arrêter à  la ligne où il y a un problème !




     


     


    Okay cool du coup j'opterai ça dans un futur proche

  • AliGatorAliGator Membre, Modérateur
    octobre 2014 modifié #13


    Bah il y a pas qu'une seul fonction dans le log disons que je ne savais pas laquel prendre bref.

    Tu veux dire que tu n'as jamais vu une callstack (ou stacktrace) ? Sans même parler de crashlog je veux dire ? Comment tu fais pour debuguer alors, quand tu es dans le debuguer t'as jamais regardé la callstack pour savoir qu'elle méthode avait appelé la methode où tu t'es arrêté, d'où vient l'appel, etc ? (ce n'est donc pas une question de crashlog là , tu vois ces callstacks partout dans le debuguer)
  • Am_MeAm_Me Membre
    #14

    Ah j'ai ma technique à  proprement dite : NSLog(). Je l'utilisais souvent en C avec la masse de printf et voir lequel est le dernier à  avoir été appelé. Ensuite en Obj-C j'ai essayé de faire en sorte de n'avoir jamais ce type d'exception ...

  • colas_colas_ Membre
    #15

    Tu peux cliquer sur https://www.youtube.com/watch?v=9IRw1d7inbY.


     


    Ou plus généralement sur https://www.youtube.com/results?search_query=debugger+xcode.


     


    ça va te prendre 10 minutes mais après tu auras gagné plusieurs après-midi...


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