Discussion :

[Caine]

Bonjour,
Mon expérience professionnelle et personnelle m’a appris que bien debuguer consiste à prévoir cette phase essentielle dès le départ d’un projet. Voici les trois phases d’un bon debug :

1) Dés l’étude du cahier des charges, quand on prend connaissance des fonctionnalités de l’application, il est utile de prévoir les tests globaux du projet suivant les contraintes, les objectifs et l’ergonomie de l’application.
2) Lors de la conception, plus approfondie, mais surtout avant d’avoir les premiers jets de lignes de code, élaborer une vision de l’ensemble des tests unitaires, ainsi que de l’ensemble des tests d’intégration de l’application.
3) Maintenant les tests listés, commencer à développer les utilitaires de tests.

Pourquoi se lancer dans l’étude des tests si tôt ? Avant même d’avoir les premières lignes de codes ? La raison est simple : Une fois lancé dans le développement proprement dit, on perd la vision de l’ensemble. Il y a le risque d’oublier des interactions entre modules, ou bien encore carrément de tester certaines valeurs triviales. C’est pourtant sur ces points que l’utilisateur final (un client, un prof…) ne manquera pas de tomber sans forcer le jour J.
De plus si dés la conception, vous affinez la liste des tests d’intégrations, vous gagnerez du tant lorsqu’un test unitaire échouera au cours de l’évolution du logiciel. En effet, plutôt que de recommencer l’ensemble des tests suite à une correction dans un modules, vous serez quels tests d’intégration rejouer à coup sûr.

Sans rentrer dans le détail pour ce qui est des tests unitaires (choisir errorno, fprintf avec stderr…), voici quelques conseils :
1) Ecrire un code clair : Indenter les sources proprement, écrivez des commentaires précis, pertinents et concis (pas besoin de romans).
2) Tout bloc de code ne servan,t qu’au debug (même la plus petite déclaration) doit être inclus dans un bloc conditionnel.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#ifdef _debug
…
#else
…
#endif

3) Vérifier systématiquement les arguments des fonctions et procédures avec des assertions. Si vous connaissez la preuve algorithmique, n’hésitez pas en faire usage.
4) Préférez des test automatisés à des tests manuels.

Enfin, une fois cette phase achevée, n’oubliez pas des tests de monter en charge de l’application ou de performance : Charge CPU, Vérifier qu’il n’y a pas de fuites mémoires …

Bon débug à tous, et toutes

[xylo]

juste un complément pour faire de belles traces...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
#define USE_TRACE
 
/* macro de trace
 * UTILISATION: TRACE(("%s", string))
 * ne pas oublier les doubles parenthèses
 *---------------------------------------------------
 */
#ifdef USE_TRACE
# define TRACE(a) do		\
    { printf("TRACE: ");	\
      printf a;			\
      fflush(stdout);		\
      break;			\
    }while(1);
#else
# define TRACE(a)
#endif

et l'utilisation ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
TRACE(("Error %d : texte %s", err, "Complément"));

Ce qui est interessant ici c'est que vous pouvez à la volée préciser votre format pour le printf.

'Content de peu n'a rien à craindre'
http://jm.marino.free.fr

[Emmanuel Delahaye]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
# define TRACE(a) do		\
    { printf("TRACE: ");	\
      printf a;			\
      fflush(stdout);		\
      break;			\
    }while(1);

C'est pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

}while(1);

, c'est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

     }while(0)

sans ';'...

C'est drôlement compliqué... Tiré de ma bibliothèque:

http://emmanuel-delahaye.developpez....b/ed/inc/sys.h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
/* printf programmable (debug)
 * usage : PRINTF (("Hi, I'm %d years old\n", 48))
 */
#define PRINTF(s)                   \
   printf s

[ylanglais]

Lut
Si bien que l'on ne s'est pas quel debugger il faut préférer:Vous utilisez lequel?
Souos windows comme sous linux?

gdb
dbx sous solaris quand gdb n'est pas dispo (et que je ne suis pas root).

[fab_hunter1100]

Beaucoup de chose ont dejà été dites , j ajoute juste ma petite contribution, la difference entre les termes : Error/Fault/Failure , Important car aidant a identifier le bug a savoir où chercher .

Error: Erreure (de pensée) du Programmeur . par exemple confondre les format europeen et americain de la date : dd/mm/yy ou mm/dd/yy , erreures de syntaxe ......

Fault : C est une erreur survenue (peut etre causer par un Error) dans le System . rend le systeme instable et imprevisible . Par exemple chez le client seulement apres avoir entrer un format incorrect que surviendra le "Fault" dans le systeme , pouvant provoquer l arret, ou un comportement bizare .

Failure : Erreur permanente dans le system . Survient quand le systeme ne rempli pas correctement et entierement sa tache . Les "Fault" conduise souvent aux "Failure".

*Solution avant de commencer un Projet :
- Bien s informer sur les Spec et et les standard , appliqué les recommandation , s impregner theoriquement du domaine dans lequel on va travailler ("Il y a rien de plus pratique qu une bonne theorie"), toujours tenir un cahier de charge.

Petit bonus : Considerer les Warnings comme des Erreures , essayer de les faires disparaitre , Si ce n est pas possible , bien documenter les Warnings presents dans le Code et expliquer pourquoi ils n ont pas pu etre dissoute .

[ylanglais]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
# define TRACE(a) do		\
    { printf("TRACE: ");	\
      printf a;			\
      fflush(stdout);		\
      break;			\
    }while(1);

C'est pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

}while(1);

, c'est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

     }while(0)

sans ';'...

C'est drôlement compliqué... Tiré de ma bibliothèque:

http://emmanuel-delahaye.developpez....b/ed/inc/sys.h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
/* printf programmable (debug)
 * usage : PRINTF (("Hi, I'm %d years old\n", 48))
 */
#define PRINTF(s)                   \
   printf s

Un peu plus compliqué, et n'étant actif que lorsque la variable DBUG est déclarée dans l'environnement (et, bien sur compilé avec l'option -D__debug__) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
#include <stdio.h>
#define _debug_c_
#include <debug.h>
#undef  _debug_c_
#include <stdarg.h>
 
void 
_dbg_full(char *file, int line, char *func, char *fmt, ... ) {
    va_list args;
    char buf[1024], buf2[1024];
    va_start(args, fmt);
		 if (!getenv("RPTDBG")) return;
		 if (func) {
		 		 sprintf(buf2, "%s (%s:%d): %s", func, file, line, fmt);
		 } else {
		 		 sprintf(buf2, "%s:%d: %s", file, line, fmt);
		 }
    vsprintf(buf, buf2, args);
    fprintf(stderr, "%s\n", buf);
    va_end(args);
}
 
void  dbg_print(char *fmt, ... ) {
    va_list args;
    va_start(args, fmt);
		 if (getenv("DBUG")) vfprintf(stderr, fmt, args);
    va_end(args);
}

Et le header :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
#ifndef _debug_h_
#define _debug_h_
#if defined(__debug__) || defined(_debug_c_)
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
void  _dbg_full(char *file, int line, char* func, char *fmt, ...);
void  dbg_print(char *fmt, ...);
#ifdef __cplusplus
}
#endif /*__cplusplus */
 
#ifndef _debug_c_
#define dbg_full(fmt, ...) _dbg_full(__FILE__, __LINE__, __func__, fmt , __VA_ARGS__)
#endif
 
#else
#define dbg_full(...) 
#define dbg_print(...)
#endif 
 
#endif

[DavG]

Un peu plus compliqué, et n'étant actif que lorsque la variable DBUG est déclarée dans l'environnement (et, bien sur compilé avec l'option -D__debug__) :

C'est en effet très compliqué :
- le getenv à chaque fois ça donne une fonction très lente simplement pour pouvoir changer le mode de debug "on the fly"
- __func__ n'est pas portable

Personnellement j'utilise la même fonction que ton dbg_print avec un masque pour des niveaux de debug et le __LINE__ et __FILE__ comme paramètres ajoutés, ce qui permet un changement de niveau par simple appui de touche de debug. Une version plus évoluée peut ajouter un timestamp à chaque affichage, faire un fichier de log,...

debug.h :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
#define DEBUG_OFF 0
#define DEBUG_ON 1
 
#define CRITICAL 0x01
#define ERROR    0x02
#define WARNING  0x04
#define INFO     0x08
#define TRACE    0x10
#define TIME     0x20
void DebugLevel ( unsigned char mask, int set );
void  DbgPrintf (unsigned char mask, char *file,int line, char *fmt, ... );

debug.c :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
#include <stdio.h>
#include <stdarg.h>
 
#include "debug.h"
 
static unsigned char dbg_mask = 0x00;
 
void DebugLevel ( unsigned char mask, int set )
{
     if ( set )
        dbg_mask |= mask;
     else
        dbg_mask &= ~mask;
}
 
void  DbgPrintf (unsigned char mask, char *file,int line, char *fmt, ... ) 
{
   if ( dbg_mask & mask )
   {
       va_list args;
       va_start(args, fmt);
       vfprintf(stderr, fmt, args);
       va_end(args);
   }
}

[ylanglais]

C'est en effet très compliqué :
- le getenv à chaque fois ça donne une fonction très lente simplement
pour pouvoir changer le mode de debug "on the fly"

En fait, il n'est lent que lorsque l'application est compilée en mode __debug__. Quand ton appli, ou ta bibliothèque est ne mode normal, elle n'effectue même pas les appels.

- __func__ n'est pas portable

__func__ fait partie du C99 et par conséquent est supposée exister sur les compilateurs C99 qui, même si à l'instar de gcc ne le supportent qu'incomplètement, ont tendance à supporter __func__.

En fait, là où la portabilité est plus douteuse vient des defines à arguments variables qui, d'un compilateur à l'autre ne sont pas tout à fait géré de la même manière.

Personnellement j'utilise la même fonction que ton dbg_print avec un masque pour des niveaux de debug et le __LINE__ et __FILE__ comme paramètres ajoutés, ce qui permet un changement de niveau par simple appui de touche de debug. Une version plus évoluée peut ajouter un timestamp à chaque affichage, faire un fichier de log,...

Cette méthode est en effet très intéressante. Il serait d'ailleurs intéressant de la généraliser un peu :
Lorsque l'on utilise beaucoup de bibliothèques, la nécessité de debug "vertical" (par degré) est réduite au noyau du programme.

Par contre, en ajoutant un paramétrage "horizontal" dépendant du "module" ou de la bibliothèque en conjonction avec le niveau de débug pourrait être intéressant.

La problématique est un peu similaire pour la gestion traditionnelle des erreurs, i.e. sans passer par les setjmp/longjmp, (code de retour par rapport à la fonction du module).

C'est un sujet de réflexion intéressant.

[DavG]

__func__ fait parte du C99 et par conséquent est supposée exister sur les compilateurs C99 qui, même si à l'instar de gcc ne le supportent qu'incomplètement, ont tendence à supporter __func__.

C'est ce que je voulais dire par "non portable", tu as raison de dire que le C99 le supporte, mais C99 en lui-même n'est pas supporté par beaucoup de compilateurs pour le moment et des tas d'entre eux circulent encore sans cette fonctionnalité !!
Pour utiliser des fonctions spécifiques gcc, je me suis servis à un moment d'un mode de trace avec le builtin_return_address, très intéressant puisque tu peux remonter tout l'historique des appels de ta fonction sur le stack (le return_address[0], return_address[1], ... plus les accès aux paramètres passés à la fonction un peu comme l'output de tt (taskTrace) de vxWorks, malheureusement ce n'est pas non plus portable

[ylanglais]

Pour utiliser des fonctions spécifiques gcc, je me suis servis à un moment d'un mode de trace avec le builtin_return_address, très intéressant puisque tu peux remonter tout l'historique des appels de ta fonction sur le stack (le return_address[0], return_address[1], ... plus les accès aux paramètres passés à la fonction un peu comme l'output de tt (taskTrace) de vxWorks, malheureusement ce n'est pas non plus portable [/quote]

J'ai aussi implémenté un stack trace pour une des version de mon débugger mémoire, sans les return adresses de gcc. Son degré de portabilité n'est pas encore parfait mais il fonctionne pas mal sous linux et solaris.

Si ca t'intéresse, il est à l'url http://ilay.org/yann/articles/memdbg/stack.c.
Il va de pair avec l'allocateur mais il est facile de débrancher la dépendance à ce dernier (_mdbg_morecore() est à remplacer par un malloc).

[DavG]

Si ca t'intéresse, il est à l'url http://ilay.org/yann/articles/memdbg/stack.c.

Ça m'intéresse en effet .. par contre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
404 - Not Found
 
The requested URL /yann/articles/memdbg/stack.c. was not found on this server.

J'ai hâte de lire ton code !!

[gege2061]

Si ca t'intéresse, il est à l'url http://ilay.org/yann/articles/memdbg/stack.c.

Ça m'intéresse en effet .. par contre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
404 - Not Found
 
The requested URL /yann/articles/memdbg/stack.c. was not found on this server.

J'ai hâte de lire ton code !!

Un petit effort: http://ilay.org/yann/articles/memdbg/
en plus il y a plein d'articles: http://ilay.org/yann/articles/
Je vai les prendre pour les lire avant de me couché :win:
Y a intéret à ce qu'il n'y ai pas d'erreur, sinon demain tu vas m'entendre

[DavG]

Un petit effort: http://ilay.org/yann/articles/memdbg/

Je me sens pas fort sur ce coup là

[ylanglais]

Un petit effort: http://ilay.org/yann/articles/memdbg/

Je me sens pas fort sur ce coup là

oops:
Il y avait un signe de ponctuation dans la phrase qui a été interprété comme partie de l'url.
Il fallait lire http://ilay.org/yann/articles/memdbg/stack.c.
Pardon pour cette faute idiote.

Pour l'article sur le débugger mémoire, il est .... à faire

je viens de rajouter tout le répertoire de test préalable à l'article :
http://ilay.org/yann/articles/memdbg/mdbg.tgz

J'accepte toute remarque et correction avec plaisir.

Comme l'allocateur n'est pas des plus fiables, je bosse sur un allocateur basé sur mmap/ftruncate/munmap....

A+[/url]

[Pouic]

Tiens, depuis le temps, je n'avais pas lu ce post-it...

C'est drôlement compliqué... Tiré de ma bibliothèque:

http://emmanuel-delahaye.developpez....b/ed/inc/sys.h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
/* printf programmable (debug)
 * usage : PRINTF (("Hi, I'm %d years old\n", 48))
 */
#define PRINTF(s)                   \
   printf s

Si on veut garder la meme simplicité d'utilisation que le PRINTF d'Emmanuel, mais sans s'embêter avec les doubles parenthèses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define DEBUG(x...) printf(x)

Et ca s'utilise comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
DEBUG("%d %s", 1, "chaine");

Voilou

[Emmanuel Delahaye]

Si on veut garder la meme simplicité d'utilisation que le PRINTF d'Emmanuel, mais sans s'embêter avec les doubles parenthèses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define DEBUG(x...) printf(x)

Et ca s'utilise comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
DEBUG("%d %s", 1, "chaine");

Voilou

Pas standard C90.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

../main.c:14:16: warning: ISO C does not permit named variadic macros

Je crois savoir qu'il existe une version C99 de la chose.

[Pouic]

Pas standard C90.

Ah, oups, le flag -pedantic de gcc n'était pas mis sur la bécane sur laquelle je suis actuellement : du coup, j'ai rien vu.... (c'est bien du C99, et ca va avec la macro __VA_ARGS__, après vérification...)
Sorry...

[gege2061]

Je vai completer un peu ce qui a été dit, pour tracer l'exécution du programme (généralement pour où ça plante), une petite macro :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define DP printf ("%S:%d\n", __FILE__, __LINE__)

un simple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DP;

Etalé sur une dizaines de lignes, on obtient un message différents à chaque ligne!

Pour ce qui est de l'allocation mémoire, j'ai trouvé cet article : Allocation de mémoire sécurisée en C et C++. Bon le mélange C et C++ ne me plait pas de trop, de même que le fait de redéfinir *alloc/free par des macro oblige à inclure le fichier d'en tête en dernier, mais le principe est trés interessant : en particulier pour la détection d'Under/Overflow et le cheksum de la structure qui sert à stocker les données de l'allocation.

Bon débugage à tous

[Damax]

- compiler avec le maximum de warnings (-Wall pour gcc).

J'irai plus loin en mettant : -W -Wall -ansi -pendantic

pas necessairement, des fois on veux allouer et ne pas free tout de suite, exemple avec les listes chainers

il faut juste faire tres attention a la gestion de la memoire

Ouais faut faire attention aus fuites de mémoire mais qu'est ce que tu fais des fuites mémoires des fonctions système ? Fonction que tu utilise quelques lignes plus bas. Donc comme tu dis "attention à la gestion de la mémoire"



désolé après je n'ai que survolé mais parlé de gestion de mémoire en utilisant une fonction système qui ne free pas son malloc, ça me dérange

[Emmanuel Delahaye]

J'irai plus loin en mettant : -W -Wall -ansi -pendantic

Je recommande ceci :

http://emmanuel-delahaye.developpez....-codage-c/#LVI