Discussion :

[manpe]

Bonjour,

Je cherche à déboguer mon appli multithread temps réel (boucle temps réelle cadencée à 25 ms).

Ce logiciel tourne en temps normal sous vxWorks cependant j'en ai fait un démonstrateur sous Linux (Mandriva), qui marche bien, mais je n'arrive pas à faire fonctionner de manière utile gdb (j'utilise kdbg comme front end, mais c'est un détail). Voila mon problème :
Si je met 1 (ou plusieurs) points d'arrêt avant le lancement de la boucle temps réel, je peux faire du step sans problème. Faire quelques tours de boucle en step même, tout fonctionne ! Sauf qu'à appuyer sur F10 même à fond les ballons ca ne risque pas de marcher à 25ms. Le problème est que si je lache la bête (je désactive tous les breakpoints et je fais continue), le logiciel fonctionne très bien, mais le débogueur ne le contrôle plus et ne donne plus aucune information utile. La seule chose que je puisse faire c'est fair "Interrupt" puis de nouveau continue ... vous vous doutez que ce n'est pas vraiment le but ultime

Quelle peut être la cause du problème ? et surtout comment le résoudre ? :/
De manière plus générale, y'a-t-il des techniques plus sioux pour déboguer les applications multithreadées ?

Merci d'avance !

[Ashin]

quels problèmes ça posent si ton appli tourne pas a 25ms pendant le debug ??

peut etre que si tu savais ce que tu voulais savoir tu saurais ou t arreter sans faire du step by step



sinon il reste toujours la bonne vieille méthode des printf

[souviron34]

Bonjour,

Je cherche à déboguer mon appli multithread temps réel (boucle temps réelle cadencée à 25 ms).

Ce logiciel tourne en temps normal sous vxWorks cependant j'en ai fait un démonstrateur sous Linux (Mandriva), qui marche bien, mais je n'arrive pas à faire fonctionner de manière utile gdb (j'utilise kdbg comme front end, mais c'est un détail). Voila mon problème :
Si je met 1 (ou plusieurs) points d'arrêt avant le lancement de la boucle temps réel, je peux faire du step sans problème. Faire quelques tours de boucle en step même, tout fonctionne ! Sauf qu'à appuyer sur F10 même à fond les ballons ca ne risque pas de marcher à 25ms. Le problème est que si je lache la bête (je désactive tous les breakpoints et je fais continue), le logiciel fonctionne très bien, mais le débogueur ne le contrôle plus et ne donne plus aucune information utile. La seule chose que je puisse faire c'est fair "Interrupt" puis de nouveau continue ... vous vous doutez que ce n'est pas vraiment le but ultime

Quelle peut être la cause du problème ? et surtout comment le résoudre ? :/
De manière plus générale, y'a-t-il des techniques plus sioux pour déboguer les applications multithreadées ?

Merci d'avance !

Pour les trheads, je ne sais pas (mais je suppose) que les threads ont des proces id différents, mêmes si ils ont tou le même père..

du peux alors lancer gdb (ou ddd), une fois que le prog à démrarrer, avec l'option -pid=id.. Cela va ouvrir une fenêtre (avec ddd) en ayant le bon thread.. En tous cas moi c'est ce que je fais avec des serveurs (et les enfants créés par fork).

Maintenant, si tu n'as plus de problème quand tu lances avec un débuggeur, c'est que cela concerne forcément une erreur de mémoire.. dépassement, corruption, etc etc..

Enfin un outil très efficace est le fprintf(stderr...). C'est synchrone..

[Ma7moo7]

Pour les trheads, je ne sais pas (mais je suppose) que les threads ont des proces id différents, mêmes si ils ont tou le même père..

Les threads font partie du meme processus, ils ont donc le meme pid.. pour les différencier chacun a son TID qui est retournée lors du pthread_create(..)

[nicolas.sitbon]

Les threads font partie du meme processus, ils ont donc le meme pid.. pour les différencier chacun a son TID qui est retournée lors du pthread_create(..)

Non sous linux les threads sont implémentés au moyen de processus qui partage leur espace d'adressage, la glibc masque l'implémentation mais le retour de pthread_create n'est pas le vrai TID, pour cela il y a un syscall sys_gettid(), qui renvoi en réalité le pid du thread (i.e processus) et getpid() renvoi le tgid (thread group id) qui n'est autre que le pid du processus initial (celui qui à lancer main(). Il arrive souvent (surtout à des fins de debug en fait) que l'on ai besoin de passer cette abstraction POSIX offerte par la glibc.

[NiamorH]

Déjà, parsème ton code avec des assert pour vérifier les invariants de tes fonctions. Si ce n'est pas déjà fait tu verras que tu détecteras bien plus vite d'éventuels problèmes.

Ensuite, je ne comprends pas trop, tu débugges juste pour le plaisir de voir ton code déroulé ou tu as déjà des problèmes d'accès concurrents à identifier ?