Discussion :

[uriotcea]

Bonjour,

J'ai un code assez lourd, même tres lourd ecrit en C++ + Qt4 qui fonctionne bien sous windows et linux mais qui persente des plantages intenpestifs que je n'arrive pas à isoler.
J'ai essayer de le compiler avec l'option electric-fence mais à l'execution j'ai sytématiquement des erreurs du type :

ElectricFence Exiting: mprotect() failed: Cannot allocate memory

J'ai alors essayé Valgrind, mais la mon applie s'affiche et se plante dé quelle s'affiche. J'ai bien avancé en reduisant certaine resource de mon appli mais que je lance une tache un peu complexe, valgrind se plante. Enfin, ca m'a l'air trés instable dé que l'appli est un peu grosse

Je ne sais plus quel outil essayer sous linux alors je me suis tourné sous windows, mais là avant j'utilisais CodeCard de builder qui était génial, mais depuis que je suis passé à gcc, je ne sais pas trop quoi utiliser pour tester mes appli

Merci de vos suggestions

[LittleWhite]

Sous linux , pour du débuggage tu as gdb et son interface graphique ddd.
Par contre rajoute l'option -ggdb3 ( ou -g seulement ) lorsque tu compile.

Sous windows, code::blocks à un debuggeur ( et il utilise le portage de gcc ).
Visual Studio aussi à un très bon outils intégré à l'IDE , mais il faut reussir à relancer le projet avec celui ci.

Bonne chance pour ton debuggage ... c'est ton programme ? où tu choppe un programme avec plein de bug ?

[uriotcea]

Je n'ai pas été assez clair!
J'utilise codeblock, j'ai donc bien un debugger, mais ce n'est pas suffisant dans certain cas trop complexe. Là j'ai bseoin d'un checker de memoire. Un outil permettant de te dire par example que tu accedes à un indice de tableau superieur à celui déclarée par malloc ou new ou même [].

[Cheps]

En principe un debugger suffit pour ça. Quand tu as un accès en dehors des limites d'un tableau, ton programme plante et ton debugger te montre la ligne où ça a planté.

[Spout]

En principe un debugger suffit pour ça. Quand tu as un accès en dehors des limites d'un tableau, ton programme plante et ton debugger te montre la ligne où ça a planté.

Et du coup tu as juste à remonter la pile des appels pour trouver ce qui pose problème dans ton code (parce qu'on tombe souvent dans du code machine ou CRT ou autre ...).
Mais effectivement, dans ce cas précis, le débuggeur suffit.

Pour les new et des éventuelles fuites mémoire (qui peuvent être source de bug filous) je ne sais pas si Qt a un truc genre DEBUG_NEW à la Visual qui te donne la ligne d'allocation en cas de fuite. Toujours en debug.

En bref, je ne sais pas si un tel outil (i.e. capable de recoller les morceaux) existe. Il aurait fallu être clean dès le début, mais d'une part c'est pas toujours facile, et d'autre part on n'y peut rien quand on récupère du code.

En derniers recours, tu peux toujours passer un outil d'analyse statique de code du type C++Test ou un équivalent gratuit, qui te dira les variables non initialisées, les variables non utilisées, ... bref ça peut pas faire de mal. Mais ça ne fera pas de miracles non plus.

Bon courage

[uriotcea]

Les libraries ou outils tels que memprof, valgrind, electic fence, codegarde(borland)... et j'en oublie, n'ont pas été dévelopés pour rien vous savez!

En particulier sous windows, ce n'est pas parce que l'on fait un accé memoire non autorisé que l'on va planter le code, et souvent ca plante mais pas du tout à l'endroit attendu (parfois l'erreur est tellement indirect qu'il est impossible de mettre la main dessus.)
Quand je developais sous builder de borlandc cette outil m'a fait gagner un temps précieux et je ne vous dis pas le nombre de collégues qui m'ont amener leurs codes pour que je mette la main sur le bug qu'il cherchait depuis des jours sans succé. Et avec ce type d'outil en 2 secondes c'est réglé.