🚀 go-pugleaf

Erwan David <erwan@rail.eu.org> writes:

[contexte laiss� en entier pour fr.comp.developpement]

> "TigrouMeow" <TigrouMeow-NOSPAM@ANTISPAM-OnLine.Fr> writes:
>
>>> > Tu as sans doute un d�bordement de buffer ailleurs, qui vient casser
>>> > les donn�es � secr�tes � autour d'un des tes blocs, lesquelles servent
>>> > � g�rer le cha�nage des blocs de m�moire. Quand malloc() veut sauter de
>>> > bloc en bloc pour trouver de la place libre, boum...
>>>
>>> Tu identifies la ligne qui plante (ton bloc qui � �t� cass�) , avec ton
>>> debuggueur, et surtout, la zone m�moire. Ensuite, tu executes ton
>>> programme avec un oeil sur la zone m�moire en question(et ses alentours
>>> proches) , et tu regardes � quel moment cette zone m�moire est modifi�e,
>>> alors qu'elle ne devrait pas l'�tre.
>>
>> J'aimerai beaucoup faire ca ...
>> Mais j'utilise gdb pour debugger et je suis un peu debutant donc... je ne
>> sais vraiment pas comment faire. La seule chose que j'arrive a savoir c'est
>> que malloc segfault a tel ligne...
>
> dans ces cas l� j'utilise electricfence, une biblioth�que qui met des
> pages non accessibles autour de chaque bloc allou�.
> Du coup les d�bordements se d�tectent par un segfault au moment du
> d�bordement.
> C'est tr�s efficace.

Sous linux/ix86 (et peut-�tre d'autres plateformes) il y a aussi
valgrind qui �mule le processeur et controle les acc�s m�moire.

Mais ce n'est pas sp�cifique au C. Suite dans fr.comp.developpement

-- 
 J'aimerais bien les plans de la lampe !
 Que feront les g�n�rations futures avec tous nos CD ?
 Des pieds de table peut-�tre ? Avec des plateaux en disquettes ???
 -+- CH in Guide du Macounet Pervers : CDs MacWorld FR: Enfin utiles! -+-