Comment bien debugger son code ?

[ylanglais]

Envoyé par Emmanuel Delahaye

C'est pas

Code :

}while(1);

, c'est

Code :

     }while(0)

sans ';'...

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

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

Code :

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 :

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 :

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]

Envoyé par ylanglais

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 :

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 :

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]

Envoyé par ylanglais

__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]

Envoyé par ylanglais

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 :

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]

Envoyé par DavG

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

Code :

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]

Envoyé par gege2061

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

Je me sens pas fort sur ce coup là

[ylanglais]

Envoyé par DavG

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...

Envoyé par Emmanuel Delahaye

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

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

Code :

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 :

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

Et ca s'utilise comme ça :

Code :

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

Voilou

[Emmanuel Delahaye]

Envoyé par Pouic

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 :

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

Et ca s'utilise comme ça :

Code :

Voilou

Pas standard C90.

Code :

../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]

Envoyé par Emmanuel Delahaye

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 :

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

un simple

Code :

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

[sysyphe]

Envoyé par batmatm

stderr est toujours affiché tout simplement parce que cette sortie n'est pas bufferisée, contrairement à stdout [/code]

@++

Salut ++

je trouve ce le sujet de cette rubrique très intéressant pour un débutant comme moi, apprenant tout seul.
Je tente de lire petit à petit les commentaires de chacun et de d' assimiler les diverses notions.

Une précision; qu 'entendez vous par "buffériser"?

[Emmanuel Delahaye]

Envoyé par sysyphe

Une précision; qu 'entendez vous par "buffériser"?

http://emmanuel-delahaye.developpez....e=Page6#LXXXIV

Pose des questions si tu ne comprends pas.

[sysyphe]

Envoyé par Emmanuel Delahaye

http://emmanuel-delahaye.developpez....e=Page6#LXXXIV

Pose des questions si tu ne comprends pas.

Merci je pense avoir compris cette notion de "buffériser".

Une question :
les divers macros de "trace de programme" présentées dans cette discussions, servent à remplacer l' usage d' un outilitare pour "debugger" ou s' utilise en complément ?

[Emmanuel Delahaye]

Envoyé par sysyphe

les divers macros de "trace de programme" présentées dans cette discussions, servent à remplacer l' usage d' un outilitare pour "debugger" ou s' utilise en complément ?

Souvent, j'ai du débugger des programmes sur lesquels la notion de 'débugger' était quasi inexistante. Les traces permettent de s'en sortir quasiment à tous les coups, à condition d'avoir un stdout (port série, par excemple) sur la cible.

C'est aussi très utile pour mettre au point une application graphique (trace dans un fichier ou le port série).

[bibilolo2]

Pour éviter l'erreur de syntaxe d'écriture de test (variable=0) on peut écrire (0==variable).
C'est plus difficile de se tromper maintenant .

Pour savoir si l'implémentation du compilateur est conforme au standard AINSI C99, la constante

Code :

__STDC_VERSION__

doit être égale à "199901L".
Correction en rouge et merci à nicolas.sitbon

[Damax]

Envoyé par D[r]eadLock

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

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

Envoyé par Fatalis

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]

Envoyé par Damax

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

Je recommande ceci :

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