Bonjour,

En me basant sur la GNU CommonCPP librairie, j'ai fait un programme de daemon reseau "multi-thread". En gros, avec un programme comme Telnet, on peut "discuter" avec lui sur un port spécifique. On peut ouvrir plusieurs sessions en meme temp, chaque thread gerant une connection.
Mon problème est que j'ai de temps en temps un segmentation fault. d'apres le fichier core, c'est la meme classe qui en est la cause mais rarement la meme methode.
Je pense qu'un pointeur deborde de sa zone mémoire allouée mais difficile de savoir lequel.
Existe-t-il des outils sous Linux pour detecter ce genre de probleme?

Merci pour vos réponses

DDD non ?

Ou n'importe quel debugger en C++ ?

Sinon, il reste le bon vieux printf des familles qui marche assez bien (personnellement, je ne jure que par ça )

Enfin, un segfault, c'est que généralement, tu es allé tapé dans une zone mémoire non allouée avec ton pointeur...

M'enfin, bonne chance si le phénomène n'est pas récurrent

EDIT : Jette un coup d'oeil sur les synchronisations multi-threads... Le bug vient à 90% de là si ce n'est pas la même méthode à chaque fois...

Merci pour ta reponse.

Le 31 mai 2005 - 15 h 25, gege38 a écrit : DDD non ?

Ben c'est ce que j'ai utilisé jusqu'ici sans succès.

Sinon, il reste le bon vieux printf des familles qui marche assez bien (personnellement, je ne jure que par ça )

J'ai deja essayé.

Enfin, un segfault, c'est que généralement, tu es allé tapé dans une zone mémoire non allouée avec ton pointeur...

C'est ce que je crois. En fait je cherche plutot un outil orienté vers le monitoring de memoire ou de depassement de pile.

M'enfin, bonne chance si le phénomène n'est pas récurrent

C'est le cas, cela peut marcher plusieurs jours sans planté et puis un jour, PAF.

EDIT : Jette un coup d'oeil sur les synchronisations multi-threads... Le bug vient à 90% de là si ce n'est pas la même méthode à chaque fois...

Ouiais, j'ai effectivement corrigé plusieurs problème venant de là mais il me reste tout meme qqs SegFault "aleatoire", isolé et assez rare. Les threads ne partagent plus de données maintenant. C'est pour cela que je penche pour une debordement de pile.
J'ai vu quelque part qu'il existait des outils sous Linux pour monitorer la mémoire ou detecter les fuites de memoires mais impossible de retrouver leurs noms ou meme ou j'ai vu ça... Je pense qu'en les associants à DDD, je pourrai trouver le pointeur responsable.

Et sinon, as-tu essayé de poser des verrous d'exclusion mutuelle ?

Parce que là, j'ai bien l'impression qu'il doit y avoir 2 threads qui accèdent à une ressource partagée de manière aléatoire et de manière fortuite...

Faudrait voir à nettoyer le code, là, parce que sinon, des SF tu risques de t'en prendre même une fois 100% débuggé (suffit qu'il soit dans une config particulière...)

Pense à bien isoler tes variables

EDIT : Ooops, j'avais pas vu que tu disais que tu n'avais plus de ressource partagée...

Bon, donc c'est une zone mémoire qui vient dépasser la taille requise et du coup va émpiéter sur une zone mémoire d'un autre thread...

Huh, ca va être chaud chaud chaud à débugger

Sous VC++, en mode debug, il y a un mécanisme de détection de dépassement de pile (que je vais décrire selon mon souvenir) : le compilo fait en sorte qu'à chaque appel de fonction, une page de pile supplémentaire est allouée et remplie de données bien précises. En sortie de fonction, ces données sont vérifiées. Si elles sont différentes, il y a eu dépassement, et l'exécution est interrompue.

Peut-être que tu peux adapter ce système à ton code avec des macros en tête et en fin de tes fonctions ?

sinon, y'a Electric Fence (qui est payant malheureusement), il est réputé très efficace.
Sinon moi je fais comme gégé, printf à tout va. Du fait main, artisanal et rustique, mais efficace avec peu de moyens...

Le 31 mai 2005 - 20 h 49, bernie38 a écrit : sinon, y'a Electric Fence (qui est payant malheureusement), il est réputé très efficace.

Ben sur ma Fedora il est installé alors je vais l'essayer. Merci de l'info, cela semble prometteur, j'espere que cela va me permettre de regler ce pb. Je ne crois pas qu'il soit payant.

Sinon moi je fais comme gégé, printf à tout va. Du fait main, artisanal et rustique, mais efficace avec peu de moyens...

C'est vrai que cette methode a fait ses preuves quoique dans ce cas précis elle montre ses limites. En effet, le prgm plante rarement au meme endroit bien que dans la meme zone. Le fichier core me dit ou cela plante mais pas QUI est responsable ("mais pas coupable").

Comme dit Gege, ca va etre chaud... Murphy et la loi de l'emmerdement maxi ne font qu'un aujourd'hui...

Merci à tous pour vos remarques en tout cas.

gdb ?

Le 01 juin 2005 - 09 h 39, Gosseyn a écrit : Le 31 mai 2005 - 20 h 49, bernie38 a écrit : sinon, y'a Electric Fence (qui est payant malheureusement), il est réputé très efficace. Ben sur ma Fedora il est installé alors je vais l'essayer. Merci de l'info, cela semble prometteur, j'espere que cela va me permettre de regler ce pb. Je ne crois pas qu'il soit payant.

Il est meme libre .. et fait par un develo Debian

http://directory.fsf.org/All_Packages_in_Directory/ElectricFence.html

Voir aussi les autres progs suggeres sur cette page

Le 01 juin 2005 - 18 h 35, iraysyvalo a écrit : gdb ?

Tu m'arrêtes si je me trompe mais il me semble que DDD est une surcouche de GDB non ?

Oui .. je ne t'arrete pas

Disons que j'ai ete eleve a la dure avec gdb

et voila un mythe qui disparait ! Moi qui croyais que electric fence était un shareware ! Il est donc free ??? Enfin une bonne nouvelle...

Electric Fence m'a permis d'identifer le probleme rapidement. Pour les SegFault "aleatoires", cest l'outil qu'il vous faut!. ça plante au 1 er debordement de pile. Il suffit alors de regarder le core dump pour savoir ou est l'erreur.

L'utilisation est assez simple puisqu'il faut juste "linker" le programme avec la lib efence. Aucune raison de s'en passer meme s'il n'y a pas de palntage, cela permet d'eviter les surprises lorsque le soft est chez le client.

Je dirais qu'il remplace avantageusement les "printf" dans certains cas. ;-)

Ok

Au fait, c'etait quoi l'origine du pb chez toi ?

En fait j'ai trouvé ou il etait mais je ne l'ai pas resolu car ça plante dans la lib. C'est sur un Timer lie à une Socket dans un programme multi-thread.
une fonction getTimer plante en SegFault. Je dois pousser les recherche mais là je suis sur autre chose.

Le 08 juin 2005 - 13 h 40, Gosseyn a écrit : En fait j'ai trouvé ou il etait mais je ne l'ai pas resolu car ça plante dans la lib. C'est sur un Timer lie à une Socket dans un programme multi-thread. une fonction getTimer plante en SegFault. Je dois pousser les recherche mais là je suis sur autre chose.

elle est multi-thread Safe ta fonction getTimer ?

Le 08 juin 2005 - 14 h 05, bernie38 a écrit : Le 08 juin 2005 - 13 h 40, Gosseyn a écrit : En fait j'ai trouvé ou il etait mais je ne l'ai pas resolu car ça plante dans la lib. C'est sur un Timer lie à une Socket dans un programme multi-thread. une fonction getTimer plante en SegFault. Je dois pousser les recherche mais là je suis sur autre chose. elle est multi-thread Safe ta fonction getTimer ?

Ben j'en sais trop rien car il faudrait lire le source de la lib ( GNU commoncpp) et je n'ai pas pris le temps de jeter un oeil. Je dirais qu'a priori non mais je n'ai aucune certitude.

Le 08 juin 2005 - 17 h 29, Gosseyn a écrit : Ben j'en sais trop rien car il faudrait lire le source de la lib ( GNU commoncpp) et je n'ai pas pris le temps de jeter un oeil. Je dirais qu'a priori non mais je n'ai aucune certitude.

ben si elle est pas multithread safe et que tu mets ça dans un prog "multithreadé", attends toi à pas mal de soucis Ou alors, quand ton appli sera en production, faut changer de poste/de boite pour pas avoir de problème...

Avec un petit effort d'encapsulation, ça doit être jouable, non ? Une petite classe qui encadre les éléments critiques et régule les accès par des mutex, et le tour est joué !