Programation système

lodino · Le 08/06/2009, à 23:21

J'ai un problème .
Lors de l'appel de la fonction "fork()", le processus fils crée ré-exécute le code du processus père.
Autrement dit si je fait un

printf("toto")

juste avant l'appel de mon fork(), à l'exécution j'ai totototo.
Merci d'avance pour votre aide.

Dernière modification par lodino (Le 08/06/2009, à 23:51)

best_friend_fr · Le 08/06/2009, à 23:28

Salut,

Fork copie le processus, mais ne change pas le flux d'instruction. Seule différence, la valeur renvoyée par fork. Dans le processus pere, tu prends le pid du fils, et dans le fils, 0.
En gros

int main() {
  int pidFils = fork();
  if (pidFils) {
    printf("père\n");
  } else {
    printf("fils\n");
  }
}

bertrand0 · Le 08/06/2009, à 23:35

Il faut vider les buffers avant le fork, sinon les données qu'ils contiennent sont également dupliquées. Voyez la fonction fflush.

xabilon · Le 08/06/2009, à 23:37

Salut

Déplacé dans "Développement - Programmation"

lodino · Le 08/06/2009, à 23:56

merci j'essaye fflush(). J'ai demandé a un amis de compiler, exécuter le même code, et lui n'a la duplication. Vous n'auriez pas d'autre idée pour empêcher par default cette duplication ? merci.

Dernière modification par lodino (Le 08/06/2009, à 23:57)

best_friend_fr · Le 09/06/2009, à 00:01

Je t'ai mis la solution dans mon post... C'est comme ca que marche fork.

lodino · Le 09/06/2009, à 00:05

oki merci, mais comment vous expliquez que sa fonctionne sur d'autre machine et pas la mienne ?

Dernière modification par lodino (Le 09/06/2009, à 00:06)

bertrand0 · Le 09/06/2009, à 00:48

Ton problème, c'est que le buffer de sortie n'est pas toujours flushé par printf: et ce comportement dépend de la bibliothèque C à laquelle le programme est liée à la compilation (en statique) ou au chargement (en dynamique). Tu as supposé que printf affiche directement à l'écran, mais ça n'est pas le cas, il y a un buffer et la doc de printf ne garantie pas que le buffer soit flushé. (le comportement n'est pas explicitement défini, donc il ne faut pas s'appuyer sur une interprétation dans un sens ou dans l'autre.)

Si le buffer pour stdout est bien flushé avant le fork (que ce soit par printf ou par fflush), le fils reçoit une copie du buffer vide.
Si le buffer pour stdout n'est pas flushé (ni par printf ni par un autre moyen), le fils reçoit une copie du buffer contenant "toto". A un moment ou à un autre ces buffers finissent par être flushé: celui du parent ET celui du fils, d'où un double affichage.

Dernière modification par bertrand0 (Le 09/06/2009, à 00:51)

lodino · Le 09/06/2009, à 00:59

Merci Bertand pour l'explication, vraiment très bien expliqué .
Quelqu'un saurait quelle librairie installé pour que printf() n'omette plus de flushé le buffer ?

bertrand0 · Le 09/06/2009, à 01:02

Tu n'as pas besoin de choisir une bibliothèque C spécifique rien que pour ça.
Il te suffit de rajouter une commande fflush(stdout); juste avant le fork.

printf("toto");
fflush(null);
pid = fork();

Dernière modification par bertrand0 (Le 09/06/2009, à 01:05)

Bigcake · Le 09/06/2009, à 07:38

Bonjour,
tu peux soit faire un fflush après ton printf comme le dit bertrand0
Ou bien tu peut rajouter un '\n' a la fin de ton printf();
Si tu ne veut pas de retour à la ligne, tu a aussi la possibilité d'utiliser write()

printf("toto\n");
write(1, "toto", 4);

nicolas.sitbon · Le 09/06/2009, à 10:31

bertrand0 a écrit :

Ton problème, c'est que le buffer de sortie n'est pas toujours flushé par printf: et ce comportement dépend de la bibliothèque C à laquelle le programme est liée à la compilation (en statique) ou au chargement (en dynamique). Tu as supposé que printf affiche directement à l'écran, mais ça n'est pas le cas, il y a un buffer et la doc de printf ne garantie pas que le buffer soit flushé. (le comportement n'est pas explicitement défini, donc il ne faut pas s'appuyer sur une interprétation dans un sens ou dans l'autre.)

Le problème ne vient pas spécifiquement de printf() et le comportement pour les streams est explicitement défini, contrairement à ce que tu sembles penser:

3 When a stream is unbuffered,characters are intended to appear from the source or at the
destination as soon as possible. Otherwise characters may be accumulated and
transmitted to or from the host environment as a block. When a stream is fully buffered,
characters are intended to be transmitted to or from the host environment as a block when
abuffer is ﬁlled. When a stream is line buffered,characters are intended to be
transmitted to or from the host environment as a block when a new-line character is
encountered. Furthermore, characters are intended to be transmitted as a block to the host
environment when a buffer is ﬁlled, when input is requested on an unbuffered stream, or
when input is requested on a line buffered stream that requires the transmission of
characters from the host environment.

et

7 At program startup, three text streams are predeﬁned and need not be opened explicitly
— standardinput (for reading conventional input), standardoutput (for writing
conventional output), and standarderror (for writing diagnostic output). As initially
opened, the standard error stream is not fully buffered; the standard input and standard
output streams are fully buffered if and only if the stream can be determined not to refer
to an interactive device.

comme d'habitude, on retrouve un code qui utilise une fonction d'entrée sortie formatté pour une sortie non formatté, pourquoi ne pas utiliser puts() dans ce cas? ça règle les problèmes de buffering et de format string vulnerability.

bertrand0 · Le 09/06/2009, à 15:19

Je n'ai pas dit que printf avait un problème. J'ai dit que le comportement observé est la conséquence du fonctionnement de printf et de la bibliothèque C en général, ou plus spécifiquement de la présence du tampon. Ça n'est pas un problème en soi. Le problème c'est de ne pas en avoir tenu compte.

Quant à la doc, il ne suffit pas de trouver un texte qui mentionne printf et un comportement spécifique . Il faut définir si vous souhaitez fonctionner avec une implémentation spécifique de libc, ou bien vous en tenir à une spec précise, comme par exemple POSIX, C99 ... Ensuite une fois clairement définie la plateforme, vous devez voir la doc de cette plateforme ou de cette spec, et vérifier que le comportement supposé est bien défini, ou bien laissé à la discrétion de l'implémentation... Et dans des points de détail comme celui-ci, bien que je n'ai pas vérifié explicitement dans ce cas, je vous assure qu'il y a fréquemment des variations qui peuvent vous retomber dessus si vous faites trop de suppositions...

Dans le cas qui nous intéresse, vider le tampon est une solution, ouvrir un flux sans tampon en est une autre. Mais pour ma part j'estime que le problème de sortie formatée ou non, bien qu'intéressant, n'a aucun rapport avec le problème présenté. Le "format string vulnerability" est un risque certain quand il est combiné à des buffer overflows potentiels, ou en tant qu'alternative à un buffer overflow et quand on réutilise naïvement les chaînes reçues d'une source extérieure au process (entrée utilisateur , réseau ...), mais ça n'est pas la source du dédoublement de "toto"

Dernière modification par bertrand0 (Le 09/06/2009, à 15:29)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 08/06/2009, à 23:21

Programation système

#2 Le 08/06/2009, à 23:28

Re : Programation système

#3 Le 08/06/2009, à 23:35

Re : Programation système

#4 Le 08/06/2009, à 23:37

Re : Programation système

#5 Le 08/06/2009, à 23:56

Re : Programation système

#6 Le 09/06/2009, à 00:01

Re : Programation système

#7 Le 09/06/2009, à 00:05

Re : Programation système

#8 Le 09/06/2009, à 00:48

Re : Programation système

#9 Le 09/06/2009, à 00:59

Re : Programation système

#10 Le 09/06/2009, à 01:02

Re : Programation système

#11 Le 09/06/2009, à 07:38

Re : Programation système

#12 Le 09/06/2009, à 10:31

Re : Programation système

#13 Le 09/06/2009, à 15:19

Re : Programation système

Pied de page des forums