Debug DLL

Question

Bonjour,
Voici le pb sur lequel je suis bloqué depuis quelques jours.
J'ai une application qui appelle de nombreuses fois une fonction qui provient d'une dll annexe.
Il y a visiblement un bug puisque la fonction est sensée renvoyer toujours la meme valeur si les parametres qui lui sont fournis sont les memes, or il arrive (rarement mais quand meme) que la fonction renvoie 2 valeurs différentes à parametres initiaux égaux.
Le gros pb est que lorsque je lance mon application ou la dll en mode debugger pour voir à quel moment la fonction "deraille", le bug disparait ....
Pareil si j'essaye d'imprimer dans un fichier l'etat de certaines variables pour suivre le déroulement sans faire appel au debugger, le bug disparait aussi.
On m'a dit que ca pouvait ressembler à un bug de pile, et qui pourrait donc etre du à une mauvaise instruction à un tout autre endroit du programme.
Voyez vous comment je pourrais déceler d'où vient le probleme ?
Merci

cptpingu · Answer

Bonjour.

Je suppose que tu es sous Windows ?
Sous un système de type Unix, je t'aurais proposé de compiler avec DUMA ou de passer un valgrind. Sous Windows, je ne sais pas s'il existe des équivalents.
Je crois que tu peux peut être tester "vtune inspector xe" (payant, mais il y a une période d'essaie gratuite de 30 jours, ce qui pourrait te dépanner).

Si ton projet n'est pas trop gros ou confidentiel (et multiplateforme, n'ayant pas Windows), je peux essayer de jeter un coup d'oeil.

________________________________________________________________________
Historique de mes créations, et quelques articles:
[ http://0217021.free.fr/portfolio http://0217021.free.fr/portfolio]
Merci d'utiliser Réponse acceptée si un post répond à votre question

galax98 · Answer

Merci, mais malheureusement c'est du windows et que du windows, et gros de surcroit ! Je vais regarder vtune inspector.

cs_louis14 · Answer

Bonjour,
J'ai rencontré ce problème aussi une fois et c'était du aux dlls appelées qui étaient différentes en mode debug ou release. Mais il semblerait que ce n'e soit pas ton cas. 
Je te conseille de passer à ollydebug. tu adjoints le fichier pdb et map compiler en même temps que ta dll et ton exe ( tout est expliqué il me semble). Ensuite tu peux mettre un point d'arrêt avec une condition si tes variables sont différentes.
As-tu essayé de rajouter une test sur tes valeurs et de ne faire que la sauvegarde dans un fichier de tout ce qui permettrait de te donner des indications pour corriger ton code à ce moment là.

louis

galax98 · Answer

J'ai finalement fini par trouver le pb, après des heures de galère ...
Je vous livre l'objet du delit.

Fonction(int p)
int m;
if(p>5) m= ....(initialisation de m)
if((p>5)&&((m==41)||(m==42)))  { ...code1.. }
else { ...code2... }


le pb est que j'avais oublié des parenthèses et écrit

if((p>5)&&(m==41)||(m==42))

du coup il testait si m==42 quelle que soit la valeur de p, et donc dans des cas où m n'etait pas initialisée.

Or il s'est trouvé un hasard incroyable où m, qui n'etait pas initalisée (car p valait 4 par exemple), s'était vu attribuer (au hasard par le compilateur) la valeur 42 et donc code1 etait executé alors qu'il n'aurait pas du ! 
C'etait particulièrement difficile à déceler car dès que je rajoutait une variable ou un fichier pour écrire dedans, ca modifiait la valeur aléatoire donnée à m, qui n'était plus jamais 42.

Merci à tous.

cptpingu · Answer

En C++, tu as un flag qui te fait un warning pour toutes variables non initialisées.
Je ne sais pas quel compilateur tu utilises, mais sous gcc, c'est "-Wuninitialized". Je t'invite fortement à ajouter l'équivalent de cette sécurité, sur ton compilateur :)

________________________________________________________________________
Historique de mes créations, et quelques articles:
[ http://0217021.free.fr/portfolio http://0217021.free.fr/portfolio]
Merci d'utiliser Réponse acceptée si un post répond à votre question

galax98 · Answer

Effectivement c'est étrange
J'utilise Visual Studio 2008 pro, avec un niveau de warning Level 4, et rien n'est apparu.
Il faut dire que ce n'était pas exactement une variable 

int m;

mais un tableau

int m[4];

et je vois que dans ce cas, aucun warning n'apparait
Es tu d'accord ?

cptpingu · Answer

Oui, c'est normal.

"int m[4];" équivaut à "int* m = ". C'est donc considéré comme initialisé.
Vérifier, au niveau compilateur, qu'un tableau a ses cases d'alloué est bien plus complexe que vérifier si une variable est initialisée. Ça pose aussi des problèmes de performances (en temps de compil) ainsi que des soucis techniques. Les compilateurs sont rarement capables de détecter ce cas. 

________________________________________________________________________
Historique de mes créations, et quelques articles:
[ http://0217021.free.fr/portfolio http://0217021.free.fr/portfolio]
Merci d'utiliser Réponse acceptée si un post répond à votre question

galax98 · Answer

C'est un peu plus vicieux que ça apparemment :

int m[4];
if(m[0]==1) ...

déclenche un warning, mais

int m[4];
if(p==1) m[0]=0;
if(m[0]==1) ....

ne déclenche pas de warning

cptpingu · Answer

déclenche un warning, mais
ne déclenche pas de warning

C'est encore plus compliqué que cela. En fonction de si tu actives le niveau d'optimisation ou non, tu auras le warning, ou non :)
Le warning apparaît en optimisation complète, mais n'apparaît pas si tu désactives les optimisations. C'est tout simplement que ce genre de warning est calculé après optimisations. Or après optimisations, le code peut être virtuellement très différent.

Chez moi:
gcc -W -Wall -pedantic toto.c -Wuninitialized
Pas de warning.


gcc -W -Wall -pedantic toto.c -Wuninitialized -O3
toto.c: In function &#8216;main&#8217;:
toto.c:12:6: warning: &#8216;m[0]&#8217; is used uninitialized in this function [-Wuninitialized]

________________________________________________________________________
Historique de mes créations, et quelques articles:
[ http://0217021.free.fr/portfolio http://0217021.free.fr/portfolio]
Merci d'utiliser Réponse acceptée si un post répond à votre question

galax98 · Answer

A propos d'optimisation, mon projet est vraiment assez gros (environ 60.000 lignes).
En mode Release, j'arrive à le compiler sans optimisation (/Od) ou en minimize Size (/O1), mais pas en Maximize Speed (/O2) ni en Full Optimisation (/Ox).
Dans les 2 derniers cas, il reste sur Generating Code .... sans aboutir.
Est ce normal ?

cptpingu · Answer

60.000 lignes

C'est pas forcément très gros. Ça dépend la proportion de lignes "utiles" par rapport aux lignes totales. (Saut de ligne, accolades, commentaires, etc...).
Tu peux utiliser SLOC pour calculer la véritable taille d'un projet (https://en.wikipedia.org/wiki/Source_lines_of_code).

Utilitaire qui te font ça:
- http://www.cic.unb.br/~facp/cursos/ps/slides/doc/SLOCCount.html (nécessite cygwin)
- http://cloc.sourceforge.net/ (compatible Windows)


Est ce normal ?

Absolument pas. Je ne connais pas très bien le compilateur fournit avec VS. Néanmoins, l'optimisation devrait aboutir.
Il faut voir si celle-ci se termine correctement. Tu devrais essayer de lancer ta compilation en ligne de commande, et voir la sortie réelle du compilateur. Il n'y a pas de raison pour que tu ne puisses pas faire de l'optimisation "full".

PS: J'ai supprimé tes deux derniers commentaires, qui s'annulaient :) 

________________________________________________________________________
Historique de mes créations, et quelques articles:
[ http://0217021.free.fr/portfolio http://0217021.free.fr/portfolio]
Merci d'utiliser Réponse acceptée si un post répond à votre question

galax98 · Answer

Pour le code, plus de 40.000 lignes utiles d'apres cloc.
Pour lancer la compilation en ligne de commande, je ne suis pas assez calé, il y a une multitude d'options que je ne maitrise pas, de plus VS crée des repertoires Release et Debug un peu partout, alors on ne sait plus où se trouve quoi !
Tout ce que je peux te dire c'est qu'il crée un fichier BuildLog, avec comme 1ere ligne de commande :


/Ox /Oi /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /FD /EHsc /MT /Gy /Fo"Release\" /Fd"Release\vc90.pdb" /W4 /c /Zi /TP ".\source1.cpp"
".\source2.cpp"
".\source3.cpp"
".\source4.cpp"
".\source5.cpp"
".\source6.cpp"

(J'ai changé les noms des sources :))
puis il compile correctement les différents sources, et il reste bloqué sur le Build final, que je suis obligé d'interrompre.

cptpingu · Answer

Malheureusement, mes connaissances sur le compilateur fournit avec VS sont très superficielles, et je ne vais pas pouvoir t'aider :(
As-tu essayé avec un autre compilateur, pour voir si c'est bien un problème de compilateur ? (gcc, clang ?)
Ou alors, as-tu tenté de compiler avec une version plus récente du compilateur que tu utilises ? 

________________________________________________________________________
Historique de mes créations, et quelques articles:
[ http://0217021.free.fr/portfolio http://0217021.free.fr/portfolio]
Merci d'utiliser Réponse acceptée si un post répond à votre question

galax98 · Answer

Merci, je vais regarder tout ça.

racpp · Answer

Salut,
il reste sur Generating Code .... sans aboutir.
Est ce normal ?
Il va finir par générer le build ne l'interromps pas. C'est une affaire de quelques petites minutes. J'ai remarqué ce problème sous VC 2005 et 2008. Je n'ai pas essayé de le reproduire sous VC 2010 mais je pense que ce sera pareil. Je ne pense pas que la version en ligne de commande arrangera les choses car le même compilateur et éditeur de liens sont utilisés. Apparemment, cette lenteur est due au fait que l'éditeur de liens a besoin d'assez de temps pour lier les nombreux fichiers .obj. Puisque chaque fichier .obj correspond à un fichier .cpp, une solution consisterait à limiter le nombre de ces derniers pour accélérer le processus du build en mode release. D'ailleurs, pour certains de mes projets, je me force à n'avoir qu'un seul gros fichier .cpp, et là, le build en release se fait toujours instantanément.
Donc, pour résumer, moins de fichiers cpp tu as, plus le build sera rapide. A noter qu'en mode debug le problème ne se pose pas du tout. Je vais essayer de voir sous VC 2010. Je crois que GCC ne souffre pas de ce problème.

racpp · Answer

Je viens de tester sous VC 2010. Même problème.

galax98 · Answer

Peut etre, mais je n'ai pas eu le courage d'aller au dela d'une heure !

racpp · Answer

Une heure c'est trop. Pourrais-je savoir combien tu as de fichiers cpp? As-tu vérifié s'il n'y a pas un autre processus qui occupe trop le processeur? Y'a-t-il assez de RAM libre? Je suis très curieux de savoir pourquoi la génération de l'exécutable n'aboutit pas.

galax98 · Answer

Oui, c'est ce qui m'étonne aussi.
Coté RAM ca devrait aller 8Go avec horloge 3Ghz, et aucun autre processus gênant à priori.
Il n'y a que 6 fichiers cpp, mais comme je disais environ 40.000 lignes "utiles".
N'y a t il pas un moyen de "suivre la progression du build" pour voir ce qui le gène ?

racpp · Answer

Je ne connais pas de moyen pour suivre la progression du build. 
6 fichiers cpp c'est très peu. Il faudra donc regarder du coté du code source. Peut-être que quelque chose dans le code empêche l'optimisation d'aboutir. Essaie de mettre la ligne suivante juste après les includes de tous tes fichiers cpp:
#pragma optimize ("", off)
Ensuite, tu pourras mettre en commentaire cette ligne pour réactiver l'optimisation pour chaque fichier cpp un par un. Ainsi, tu finiras par trouver le fichier ou les fichiers qui causent le problème. Une fois les fichiers incriminés identifiés, la recherche de la ou des fonctions qui posent problème pourra alors commencer.

Debug DLL

30 réponses

Votre réponse

Discussions similaires