Discussion :

[Z-fly]

bonjour,

j'ai un programme qui fonctionne bien.
Sauf qu'au bout d'un moment il fait une erreure de segmentation et je ne comprend pas pourquoi
C'est un serveur mais je ne pense pas que cela vienne de la car j'ai appparement identifié la cause après des heures de tirage de cheveux: un .... free
Dur a croire n'est ce pas, et pourtant quand je commente cette ligne, le programme ne plante plus, ou du moins j'ai fait au moins 20 connexions dessus et il a pas fait l'erreur.

Comment pourrais je procéder pour identifier rélement la source de cette erreur?
ya t il des programmes pour debuger un programme et voir ce qui se passe" en interne et me montre les comportements anormaux?

Merci

P.S. ah oui pardon je sous linux.

[ram-0000]

En vrac, quelques idées :

• Tracer les malloc et les tailles allouées
• tracer les free (recherche des double free)
• Regarder que les écritures (memcpy, strcpy, sprintf, ...)se fassent dans
• des buffer suffisemment grands
• utiliser une librairie de détection des BOF (Valgrind ?)
• avec le debugger, fait un traceback du core généré pour voire où a lieu l'erreur précissement et l'état des variables sur la pile

[Z-fly]

comment on fait un traceback du core , et quel debugger ? je compile avec gcc.

[ram-0000]

le debugger, c'est gdb

backtrack c'est la commande bt (ou tb, je ne me rappelle jamais) dans gdb. Cela permet d'analyser la pile (stack) d'un binaire en cours d'exécution.

Il faut que tu crées une version de ton binaire avec les info de debug, tu le lances, tu attends que ton programme se plante, tu récupères le fichier core généré et tu lances gdb dessus.

Ca, c'est dans la théorie, cela se passe rarement aussi facilement sinon, cela serait trop facile et on aurait plus de boulot

[Obsidian]

Dur a croire n'est ce pas, et pourtant quand je commente cette ligne, le programme ne plante plus, ou du moins j'ai fait au moins 20 connexions dessus et il a pas fait l'erreur.

Comme Ram_0000 l'a dit, il s'agit probablement d'un buffer overflow. Il ya globalement trois choses qui peuvent faire planter un free() :

1) Un pointeur fou. Le pointeur qui est censé pointer la zone à libérer contient en fait une valeur farfelue pour une raison à identifier en amont.

2) La mémoire a déjà été libérée. Ça arrive par exemple si on place la directive au mauvais endroit (genre dans une boucle).

3) Dans le cas d'un buffer overflow, les données stockées ont dépassé la taille du bloc alloué et sont donc allées écraser d'éventuelles méta-données concernant ce bloc, ce qui l'empêche d'être identifié. Ça dépend de la manière dont la bibliothèque standard gère le tas.


Apprends à utiliser gdb, c'est un débogueur très efficace. Si tu places un breakpoint sur l'instruction incriminée, tu auras la chance d'examiner le contenu du pointeur passé juste avant qu'elle soit exécutée.

[Z-fly]

J'ai decouvert oui, mais c'est pas trés facile à appréhender ce gdb.
Pour l'instant j'ai réussi à faire le core de mon programme.

c'est quoi les breakpoint et comment analyser le core avec gdb?
deja apparement il me dit que c'est strlen qui plante au bout d'un moment.

[Emmanuel Delahaye]

Sauf qu'au bout d'un moment il fait une erreure de segmentation et je ne comprend pas pourquoi
C'est un serveur mais je ne pense pas que cela vienne de la car j'ai appparement identifié la cause après des heures de tirage de cheveux: un .... free
Dur a croire n'est ce pas, et pourtant quand je commente cette ligne, le programme ne plante plus, ou du moins j'ai fait au moins 20 connexions dessus et il a pas fait l'erreur.

C'est très classique. Il y a 2 causes principales qui font crasher un free()

• on ne lui a pas donné l'adresse qu'avait donné malloc() (p++ etc.)
• un débordement de zone allouée a provoqué le bazar dans le chainage des blocs.

Comment pourrais je procéder pour identifier rélement la source de cette erreur?

valgrid, efence...

Sinon, montre ton code, ça ira probablement plus vite...

[Obsidian]

c'est quoi les breakpoint et comment analyser le core avec gdb? deja apparement il me dit que c'est strlen qui plante au bout d'un moment.

Compile déjà ton programme avec l'option -g pour inclure les symboles de déboguage. Ensuite tu lances gdb de cette façon :

Code :

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

$ gdb nom_du_programme nom_du_fichier_core

Tu te retrouveras alors dans l'état exact dans lequel tu te trouvais au moment du plantage.

Un breakpoint est un point d'arrêt. Ces points d'arrêt se placent sur une instruction de ton programme. À l'exécution, lorsque cette instruction est atteinte, une interruption est déclenchée, l'exécution est suspendue et la main est provisoirement rendue à ton débogueur, qui te permet de faire les actions de ton choix puis de reprendre éventuellement l'exécution là où elle s'est arrêtée.

Les points d'arrêts sont posés soit en utilisant des registres spéciaux du processeur lorsque celui-ci est suffisamment sophistiqué, soit en modifiant directement le code en mémoire (le débogueur étant suffisamment intelligent pour se souvenir de ce qu'il y avait en dessous). Dans ce second cas, il faut faire très attention de poser le point d'arrêt au début d'une instruction et pas en plein milieu.

Tu fais b nomdefichier.c:numerodeligne pour poser un point d'arrêt.
Tu fais d ou delete pour effacer tous les points, éventuellement suivi du numéro du point d'arrêt à effacer s'il ne faut en virer qu'un seul.
Tu fais c ou continue pour reprendre l'exécution.
Tu fais bt pour voir tout ce qu'il y a dans la pile (et savoir dans quelle fonction tu te trouves).
etc.

[Z-fly]

merci beaucoup je testerai
Finalement je me suis débarrassé de cette variable lol