Discussion :

[gounon]

j'ai un problème depuis trois mois que je n'arrive pas à résoudre.
une application qui fonctionne correctement sous redhat 2.4 se bloque tous les tris jours sous redhat 2.6 avec comme point d'arrêt futex(0x3081d4f534, FUTEX_WAIT, 2, NULL
ceci est relevé grâce à strace qui permet de suivre mon process.
ce qui me chagrine le plus c'est que je ne fais pas appel à futex directement, la preuve, c'est que la seule fois que cet appel aopparaît c'est le blocage. j'ai fait le tour de la documentation NPTL sans succès, j'ai vu qu'il y avait beaucoup de logiciels qui avaient eu le même problème et qui se lançaient avec le noyau 2.4 comme palliatif.
y-a-t-il quelqu'un qui a déjà essuyé les plâtres et qui pouvait m'aiguiller vers une solution.
machine x86-64
linux redhat 2.6.18-92.1.6el5xen
glibc 2.5-24
NPTL 2.5
langage de programmation c sans gestion de thread mais des forks et des gestions de signaux et récupération des status de fin des process lancés.
je vous remercie d'avance et je continue à chercher.
petite citation de Gaston Bachelard " l'essentiel de la réflexion, c'est de comprendre qu'on n'avait pas compris"

[SYL666]

Salut,

J'ai vu de nombreux problèmes reliés à ce sujet, et aucun d'entre eux ne s'est résolu correctement. C'est un problème de race condition / deadlock, impliquant des sémaphores, me semble-t-il.

--> autrement dit, j'ai pas compris grand chose et tu vas avoir du mal à régler le problème.

Essai des trucs comme : "futex.c deadlock" dans google et tu tombera sur des messages de Linus en personne!

Bon courage! je ne pense pas que ce bug soit corrigé demain

Cédric

[gounon]

Salut,

J'ai vu de nombreux problèmes reliés à ce sujet, et aucun d'entre eux ne s'est résolu correctement. C'est un problème de race condition / deadlock, impliquant des sémaphores, me semble-t-il.

--> autrement dit, j'ai pas compris grand chose et tu vas avoir du mal à régler le problème.

Essai des trucs comme : "futex.c deadlock" dans google et tu tombera sur des messages de Linus en personne!

Bon courage! je ne pense pas que ce bug soit corrigé demain

Cédric

je te remercie beaucoup pour ton orientation qui m'a permis de résoudre cet épineux problème. je pense que tous les autres développeurs qui ont eu ce genre de problème doivent rechercher la petite bête dans leur programme. en effet il y a une liste de fonctions dites non certifiées pour leur comportement imprévisible surtout dans la gestion d'une interruption. ces fonctions sont bien celles qui figurent dans la liste donnée dans ton message. la solution avec NPTL, c'est de ne pas les utiliser dans les handler et tout le comportement de NPTL change. il suffisait que ces spécialistes nous le disent et on n'aurait pas à rechercher la cause de nos blocages ailleurs. tous mes tests sont maintenant corrects depuis une semaine.
un seul conseil avec la nouvelle gestion NPTL (futex), il faudra revoir les codes existants surtout les appels ré-entrants et ce que nous mettons dans la gestion des handlers.
pour des applications dont on ne peut pas toucher le code, je comprends que les éditeurs choisissent de figer un noyau 2.4 dans le lancement de leur produit.
encore une fois merci et j'interviendrai de temps en temps sur le site pour des problèmes de développement système (unix et linux).

[SYL666]

Et bien merci beaucoup d'avoir éclairé un peu ma propre lanterne.
Ca faisait un petit bout de temps que je voyais ce problème ici et la mais personne n'avait de solution définitive.

Cédric