processus en conflit mémoire

Bonjour,

Alors niveau environnement je suis sous : Débian et la machine c'est un raspberry B+.

Mon script python se lance avec xinit ./programme.sh , il tourne en mode graphique grace à pygame.

Jusqu'ici tout va bien,

ce script lance deux threads python.

Ensuite je veux qu'il lance un programme qui fonctionne sous X,
Le script met donc les deux threards sous pause, puis je lance le programme avec os.system("programme2")

Lorsque programme2 se termine ça plante mon serveur X avec un message d'erreur comme quoi on a violé sa mémoire. J'ai pas l'intitulé exact du message d'erreur.

Par contre si je place une pause de 4 secondes juste après os.system("programme2"), bha là ça marche. Donc quelqu'un aurait une idée pour remplacé ma pause de 4 secondes par quelque chose de plus intéligent ? Merci :P

Bonjour,

Dans l'évolution de Python, il est plutôt recommandé d'utiliser subprocess.call au lieu d'os.system: à essayer! (voir la doc du module subprocess)

Salut,

Citation:

---

Envoyé par killwin

Lorsque programme2 se termine ça plante mon serveur X avec un message d'erreur comme quoi on a violé sa mémoire. J'ai pas l'intitulé exact du message d'erreur.

---

Dommage car si le serveur X n'est pas content, c'est que vous l'utilisez peut être de travers et qu'il n'y a rien à chercher côté programmation tant qu'on ne sait pas quelles sont les contraintes à respecter lorsque...
La réponse a ce genre de question se trouve plutôt dans les forums Unix.

Citation:

---

Envoyé par killwin

ce script lance deux threads python.

Ensuite je veux qu'il lance un programme qui fonctionne sous X,
Le script met donc les deux threards sous pause, puis je lance le programme avec os.system("programme2")

Lorsque programme2 se termine ça plante mon serveur X

---

Que se passe-t-il si vous lancez directement "program2" sans jongler avec les threads avant?
note: Ici le but est d'essayer de simplifier pour essayer de mettre le doigt sur ce que le serveur X n'aime pas.

Bon courage,

- W

Bonjour,

Alors voici le message d'erreur :

[xcb] Unknow request in queue while dequeuing
[xcb] Most likely this is a multi-treading client ans XInitThreads has not been called

J'ai remplacé os.system par subprocess.check_call et c'est vrai que c'est mieux avec un choix de paramètres intéressant et l'assurance que le processus appelé se termine pour éviter les zombies.

Cependant ça ne m'a pas résolu le problème, qui survient une fois sur 7.

J'ai essayé sans créer mes threads et là ça marche bien. J'ai oublié de le dire, mais au total j'a 3 threads, dont 2 que je mets sous pause et le troisième qui tourne tout le temps pour communiquer avec le programme que je lance.

Cependant j'ai besoin de mes threads :-( merci ça avance petit à petit ...

Salut,

Que font ces threads côté GUI pour perturber le serveur X11?
(utilisez vous une bibliothèque graphique particulière?)

- W

Citation:

---

Envoyé par killwin

Lorsque programme2 se termine ça plante mon serveur X avec un message d'erreur comme quoi on a violé sa mémoire.

---

là on peut pas porté plainte contre X pour viol, c'est X la victime.

Bonjour,

Juste une idée:

Je ne connais pas pygame, mais les bibliothèques graphiques que je connais ne sont pas "thread-safe". Cela veut dire que si on a dans le thread des actions directes sur le graphique (genre affichage dans un widget), ça plante. Le problème, c'est que ça peut marcher un certain temps ou certaines fois, mais quand ça plante, c'est méchant, et il n'est pas facile de savoir pourquoi: il n'y a pas de message d'erreur explicite parce qu'il n'est pas prévu de faire comme ça!

A voir si c'est le cas dans la doc de pygame. Si c'est le cas, il faut trouver une autre manière pour les threads de piloter le graphique. Avec PyQt, le thread envoie des ordres au programme principal par des "signaux" et c'est le programme principal qui s'occupe du graphique.