ymerejt a écrit 6 commentaires

Merci beaucoup, c'est justement ce que j'allais faire. Ça n'est plus à faire. Bon, ben c'est pas gagné, il va falloir que je m'y colle vraiment ...

Merci pour ton aide.

J'oubliais presque de préciser que je suit relativement satisfait d'avoir pu avancer sur ce forum ce qui n'est pas le cas sur hardware.fr ou un dégénré au pseudo Taz sort des conneries inutiles à tout bout de bras
http://forum.hardware.fr/hardwarefr/Programmation/C-C-kernel-segmen(...)

Cela m'aide pas mal.
Il est normal qu'avec 5 sec le programme fonctionne en fait car c'est le timeout interne par défaut est de cet ordre là. En tout cas ça pose aussi problème sur ta machine.
Le seul point négatif c'est que tu utilise les noyaux gentoo comme moi ... ce qui je le reconnais est une excellente idée !!! ;) mais n'est pas terrible pour la vérification du bug.

Merci beaucoup en tout cas.

Ce sont les fichiers string et iostream (c++)


Mon investigation avance, j'ai suivit ton conseil concernant strace.
En fait sur mon 2.6.12 un appel à futex échoue alors qu'il fonctionne sur mon 2.6.11. Cet appel serait à la source d'une erreur de rétablissement de contexte du thread => segmentation fault.

Mais la question essentiel est de savoir si cela ne viens pas de mon système. Ainsi, j'espère que tu pourras tester cela ce soir.

Merci pour tout

Le problème de seg fault ne vient pas de là. Je tiens à préciser que ce programme est effectivement sale, aucuns contrôles ...
Cependant, ce n'est qu'un programme écris vite fait pour mettre en avant un bug à la fin de l'exécution de exp_fexpctl sur ma machine.
Ce que je souhaite c'est savoir si ce bug se produit sur vos machines ...
(je connais bien gdb et en ce qui concerne les fuites mémoires j'ai une certaine préférence pour valgrind)

Merci, cependant, peux-tu compiler et exécuter ce programme sur machine et me dire celà plante ou pas ainsi que quelle est la version de ton noyau ?