›

Technique de debuggage

tabliertablier Membre
dans API AppKit #1

Je travaille sur un émulateur qui utilise SDL. Le changement de certains réglages de l'émulateur oblige à  faire un reset pour être pris en compte. Parmi les réglages qui demandent un reset, ceux liés aux changement de taille de l'écran du simulateur provoquent un crash à  l'intérieur de SDL. Du moins c'est ce que montre le debugger d'Xcode (voir image)


Pour résoudre cela, j'ai essayé d'introduire les sources de SDL dans le projet de l'émulateur, mais je n'y arrive pas: erreurs, erreurs .... que je n'arrive pas à  supprimer.


Une autre solution serait d'introduire le projet SDL dans le projet de l'émulateur (sans le changer) pour debugger les deux ensemble. Mais ça je ne sais pas faire!


 


Comment cela se fait-il? 


Y-a-t-il d'autres solutions?


 

Réponses

  • FKDEVFKDEV Membre
    #2
    T'as essayé les zombies ?

    ça consiste en quoi ton reset, tu détruis et tu recrée une vue ou une fenêtre ?
  • tabliertablier Membre
    #3

    Je ne connais pas vraiment les zombies, mais c'est une occasion pour apprendre.


    Mon problème est qu'ayant utilisé cet émulateur j'ai constaté que la version linux marchait bien, mais la version OSx plantait sur certains Reset.   Je ne connais ni l'émulateur ni SDL qui sont écrits en C (je découvre). J'essaie d'aider le développeur qui à  écrit l'interface pour OSx (4 fichiers .m sur 118 fichiers au total) et qui ne se sort pas de ce problème. Donc je ne sais pas très exactement ce que fait le reset, mais je constate que le crash se produit au reset obligatoire après un changement de résolution de la fenêtre de l'Atari. Pas de crash avec les autres reset obligatoires!


    Bon, je vais allez voir les zombies (ça fait macabre).


  • berfisberfis Membre
    #4

    On appelle "zombie" un objet artificiellement gardé en mémoire par le debugger alors que son retain count est à  zéro et qu'il aurait été normalement évacué de la mémoire.


     


    L'option "Zombies activés" permet de voir si ton code fait appel à  des objets qui en principe n'existent plus. Sans cette option, un tel appel provoque un EXEC_BAD_ACCESS.


     


    Donc l'objet ne devient un zombie que si le programmeur le souhaite. Son destin normal est de défunter. C'est toi qui joues les sorciers vaudous, en quelque sorte...


  • FKDEVFKDEV Membre
    #5

    Mon intuition c'est que SDL essaye de dessiner sur une surface qui n'existe plus puisque tu es en train de faire un reset.


    Voilà  pourquoi je demandais si le reset provoque la destruction de la fenêtre et la création d'une nouvelle fenêtre.


  • FKDEVFKDEV Membre
    #6

    Bon je viens de jouer avec quelques minutes (bien que j'étais plutôt amiga...).

     

    Après avoir activé les zombies, voici le log:

     

     



    
Configured max Hatari resolution = 832x576.
    
Support for Hatari window reparenting not built in
    
Building CPU table for configuration: 68000 (compatible mode)
    
NVRAM not found at '/Users/david/.hatari/hatari.nvram'
    
VDI screen: request = 800x600@4, result = 800x592@4
    
Support for Hatari window reparenting not built in
    
2013-07-04 11:05:27.066 hatari[37331:303] *** -[b][NSWindowGraphicsContext retain]: message sent to deallocated instance 0x101d73d20[/b]

     

    Un message a été envoyé à  un objet NSWindowGraphicsContext qui n'est plus là  puisqu'on a fermé la fenêtre de l'émulateur.

    La fonction suivante n'est pas implémentée et je pense que cela pose problème :

     

     
    void Control_ReparentWindow(int width, int height, bool noembed)

    {

    /* TODO: implement the Windows part.  SDL sources offer example */
    Log_Printf(LOG_TODO, "Support for Hatari window reparenting not built in\n");

    }

  • tabliertablier Membre
    #7

    Merci pour cette aide. 


    1 je vais utiliser zombies pour bien comprendre la chose.


    2 je vais conseiller au développeur en question de consulter ce post et éventuellement de s'inscrire sur ce forum.


  • tabliertablier Membre
    août 2013 modifié #8
    J'ai trouvé le bug que je cherchais! Comme ce n'est pas courant, je vous fais un petit résumé.

    Rappel: je travaille sur l'émulateur Hatari compilé pour Mac OSx qui a une partie Objective-C, l'émulateur est programmé en C et utilise SDL.

    Effectivement zombies m'a trouvé un NSWindowGraphicsContext dont le refCt passe à  -1 et PAF (feux d'artifice, clignotant orange, appel des secours et décès du programme!!!).  Oui, mais ça ne donne pas la solution, surtout que cela se produit à  l'intérieur de SDL.

     

    Après trois semaines d'essais infructueux:

    observations: Le programme crashe lorsque l'on change les réglages de l'émulateur Atari, très exactement les réglages de l'écran Atari émulé (résolution, taille, palette..). Les autres réglages ne font pas crasher l'émulateur. A l'instant ou ces réglages sont effectués par un appel à  SDL, la fenêtre de prise des préférences est toujours affichée et elle est en mode "modal".

     

    Intuition: si un programme à  2 fenêtres d'ouvertes, si l'une est "key"+"front" et en mode "modal", l'autre fenêtre peut-elle être redessinée simultanément en arrière plan par un appel à  SDL?

     

    Vérification: j'ai mémorisé les changements de réglages a effectuer, fermé la fenêtre des réglages et son mode "modal", puis j'ai lancé l'application des nouveaux réglages. Oh merveille, plus aucun plantage.

     

    Conclusion: Eviter de modifier une fenêtre par programmation si une autre fenêtre du programme est active et modal !

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