Bonjour,
Comment initialiser le champ c.mem ? En particulier à quoi devons-nous initialiser c.mem.memory ?
A vous de voir...
(du point de vue de la Game Boy ça ne devrait pas avoir d'impact ;
du point de vue d'une programmeuse C : vous devriez être capable de faire ce choix par vous-même. ;-)
)
Merci pour la réponse.
Cependant nous avons toujours un problème avec component_create(). Les tests de component passent, mais un test de bus ne passe pas dû à un segmentation fault en appelant component_create().
Ci-joint une photo des lignes du test qui ne fonctionnent pas ainsi que l'erreur indiquée. On a de la peine à comprendre notre erreur car les tests de component passent.
De plus, on a essayé de debugger avec gdb, mais en ajoutant des breakpoints et en runnant après le programme ne s'arrête pas. Est-ce une spécificité du test ?
Bonjour,
Si vous n'arrivez à déterminer où le segmentation fault a lieu avec votre débogueur, vous aurez peut-être plus de chance avec les outils complémentaires de debugging: ASAN et Valgrind [1].
[1] https://progos.epfl.ch/projet/display.html?file=https://progos.epfl.ch/projet/handouts/dbg-ptr.md
les tests unitaires lancent en effet un nouveau sous-process par test (fork()) et c'est donc plus difficile à suivre. Si vous souhaitez debogguer avec gdb les programme de tests (mais Yassin a raison !), voici quelques conseils :
- mettez ces options dans gdb :
set follow-fork-mode child
set detach-on-fork off - suivez dans quel sous-process vous êtes avec
info infe - change de process avec infe + numéro; p.ex. :
infe 1 - ne mettez pas de breakpoints sur le code des unit-test-* eux-mêmes (car ils sont écrit avec des macros en fait) mais sur votre « vrai » code C à vous.
Exemple sur votre question :
c'est dans le 5e test que vous avez des problèmes. Ce sera donc le 5e sous-process qui vous intéresse.
On commence comme d'hab:
gdb ./unit-test-bus
On met les options suggérées :
set follow-fork-mode child
set detach-on-fork off
On met le breakpoint là où ça nous intéresse :
break component_create
Et on lance le tout :
run
gdb nous arrête au premier break. On regarde où on est :
info infe
On est dans le 2e process = le 1er test (car le 1 c'est le main et les tests créent un enfant (child process) à chaque fois) ; ce ne nous intéresse pas donc on continue :
cont
gdb nous dit que le 2e process (Inferior 2) est fini, mais lui il y est encore (faite info infe pour voir). Il faut donc le ramener au process père :
infe 1
et on continue :
cont
Il nous arrête à nouveau au breakpoint. On regarde à nouveau où on est :
info infe
Et on continue comme ça jusqu'au breakpoint qui nous intéresse.
Là on peut faire des next etc. comme d'habitude.
On peut comme ça se balader de process en process (infe <numero>) et savoir où on est (info infe).
Avec un peu d'habitude on s'y retrouve ;-)
Happy debugging!
gdb ./unit-test-bus
On met les options suggérées :
set follow-fork-mode child
set detach-on-fork off
On met le breakpoint là où ça nous intéresse :
break component_create
Et on lance le tout :
run
gdb nous arrête au premier break. On regarde où on est :
info infe
On est dans le 2e process = le 1er test (car le 1 c'est le main et les tests créent un enfant (child process) à chaque fois) ; ce ne nous intéresse pas donc on continue :
cont
gdb nous dit que le 2e process (Inferior 2) est fini, mais lui il y est encore (faite info infe pour voir). Il faut donc le ramener au process père :
infe 1
et on continue :
cont
Il nous arrête à nouveau au breakpoint. On regarde à nouveau où on est :
info infe
Et on continue comme ça jusqu'au breakpoint qui nous intéresse.
Là on peut faire des next etc. comme d'habitude.
On peut comme ça se balader de process en process (infe <numero>) et savoir où on est (info infe).
Avec un peu d'habitude on s'y retrouve ;-)
Happy debugging!
Bonsoir monsieur,
Auriez vous svp un tutoriel ou de la documentation plus spécifique à ce sujet?
Tous nos tests de jump/call ayant une condition (cc) ne passent pas et on n'arrive pas à débuguer : quand j'essaie cont j'obtiens segmentation fault et je n'arrive jamais aux breakpoints (dans mon propre code) pour trouver la source du problème.
Merci beaucoup pour votre aide,
Leo
si vous avez un SEGV, tapez la commande (gdb) « where » pour savoir où il se produit (cela affiche la pile d'appel).
Par ailleurs, pour un SEGV, peut être que valgrind ou ASAN sont plus appropriés (cf https://progos.epfl.ch/projet/handouts/dbg-ptr.pdf)
Merci beaucoup.
