Programme fou après un kill

Bonjour à tous,

je rencontre actuellement un phénomène bizarre sur un programme écrit en C pour Linux. L'appli tourne sur un noyau embarqué mais je ne pense pas que le problème vienne de là. Malheureusement je ne peux pas faire une version pour un Linux Desktop. pour vérifier. Bref, lorsque je laisse tourner mon appli (multi thread) quelques jours, il arrive qu'en "killant" celle-ci, le programme écrive sur la console plein de caractères incompréhensibles, en plus le bash pense que c'est des commandes et essaie de les exécuter. Du coup j'obtiens des messages "command not found" à tout va après la "mort de mon programme"! Par contre je n'arrive pas à recréer ce phénomène en killant mon appli après quelques heures, cela arrive toujours après 1 jour ou 2 ...

Avez vous déjà rencontré un problème similaire?
Comment un programme peut il en arriver à générer du texte qui sera exécuté par le shell, et tout ca après ca mort?

Merci 8O

Comment es-tu relié à ta cible (liaison série/réseau, terminal/remote shell) ?

Tu "kill"es ton appli avec "kill -9" ? Ou Ctrl-C ?

Je suis relié avec un port série, je kill avec CTRL-C.
Je me connecte toujours aussi en parallèle avec telnet.

Est-ce que ta liaison telnet est toujours active après ?

Si oui peux tu faire un ps pour voir si ton process tourne effectivement ?

As-tu, dans ton process, un handler pour le signal SIGINT (control c) ?

Oui le telnet tourne encore, je vais voir ce que donne le ps mais je pense que tout mes threads sont morts.

Je n'ai pas mis en place de handler de signal.

Si tous les threads sont morts, ton problème vient peut-être de la connection (bug dans le driver quand tu recois un ctrl c, bug dans ton terminal, ou je ne sais quoi encore, ...).

Disons que c'est surement en mourant que les threads engendre ce problème...
Mais je me demande d'où ca peut venir, meme si le CTRL-C est un peu brutal ca ne devrait pas arriver.

Si tu envois le ctrl-c depuis la fenetre telnet ? Cela donne quoi ?

Ben il faudrait que j'utilise plutôt la commande kill puisqu'avec une connection telnet un nouveau shell se lance. Le problème c'est que pour tester il faut attendre qq jours, ca n'arrivera jamais si je tente maintenant.
Comme si c'était après l'accumulation de qqchose que ca se produisait.

Dans tous les cas qu'elles peuvent en être les causes ?
Je vais voir si en le tuant "proprement" j'obtiens le même résultat.

Autre question : est-ce que ton programme écrit des données sur la sortie standard pendant ces jours de run ?

Je n'ai toujours pas d'idée précise sur la cause.

Mais dans le cadre de tes investigations, tu pourrais aussi essayer ceci : lorsque cela t'arrives tu débranches et rebranche le câble série.

Autre chose, si ton programme écrit sur la console, tu peux essayer de reproduire le problème en lançant un "ls -lR /" par exemple, et en l'interrompant avec ctrl-c...

Citation:

---

Autre question : est-ce que ton programme écrit des données sur la sortie standard pendant ces jours de run ?

---

Mon programme écrit des données en permanence sur la sortie standard.

Bonjour,

Citation:

---

Envoyé par adesport

Mon programme écrit des données en permanence sur la sortie standard.

---

Dans ce cas, as-tu fait le test de lancer ton programme en redirigeant la sortie standard et la sortie erreur vers des fichiers (deux fichiers distincts dans la mesure du possible) ? Si oui, peux-tu nous dire l'affichage des données lors du kill sont correctes ou non ?

Citation:

---

Envoyé par gangsoleil

Bonjour,
Dans ce cas, as-tu fait le test de lancer ton programme en redirigeant la sortie standard et la sortie erreur vers des fichiers (deux fichiers distincts dans la mesure du possible) ? Si oui, peux-tu nous dire l'affichage des données lors du kill sont correctes ou non ?

---

Salut,

Je vais essayer ca, tu veux dire avec un simple : $ ./monappli > out.txt ?
ou autre chose ?

Dans tous les cas même sis mes threads écrivent en permanence sur la stdout, un CTRL-C ne devrait leur permettre de devenir "fou"... Du coup, je vois pas trop où enquêter... :?

merci

Bonjour,

Pour rediriger les sorties vers deux fichiers différents, il faut rediriger la sortie standard (qui est identifée par le numéro 1) vers stdout dans un premier fichier, et la sortie erreur (numéro 2) vers un autre fichier :

Code:

---

1 2	./mon_appli 1>/tmp/mon_appli_stdout.log 2>/tmp/mon_appli_stderr.log

---

Citation:

---

Envoyé par adesport

un CTRL-C ne devrait leur permettre de devenir "fou"

---

Pour l'instant, aucun indice ne permet de dire que cela vienne de ton programme, ni du système, etc.

Quelque chose de bizarre se produit...
J'ai lancé l'appli en redirigeant les flux vers 2 fichiers et le fichier stdout commence à se remplir avec quelques printf() puis plus rien. Comme si mon programme n'écrivait plus sur la sortie standard, le fichier stdout.log contient donc une dizaine de ligne (les premières) seulement.

Si je lance sans redirection il y a bien des affichage sur stdout en continue.
Problème de flush() ? C'est quand même bizarre que ca ne se flush pas même au bout d'un moment ...

Les fichiers sont sur un montage nfs ou sur la cible ? La synchro peut prendre du temps !

Sur la cible.

Donc les fichiers de logs ne devraient pas mettre trois plombe à être remplis.

As-tu fait l'expérience depuis une connexion telnet aussi ? Si il faut (cela m'étonnerait, mais bon...) c'est la liaison série.

Aussi il faudrait passer ton programme à valgrind... pour voir.

Ce serait bien d'être sûr que c'est ton code qui fait n'importe quoi...

Je n'arrive pas à reproduire le phénomène pour l'instant... Je vais voir si ca se passe en telnet.