bug in glibc?

[krishnaakishore at gmail.com]

Ya I think I understand now... Thanks for your inputs... The buffers
are copied "as is" and the fork() call is flushing the buffers of the
child. The parent outputs its buffered data after many loops.

@wayne: You are right, the only difference being flush of buffers is
not triggered by printf but by fork(), because, as you can see, even
after you remove printf in child the output doesn't change, except
that there are no new-lines.

What I wish to say now is that: We can see that fork() call is
flushing the buffers in the child, but if there is a fork library call
which can flush the buffers before calling fork() system call, then
the output will be close to intuition. I would like to know your
opinions regarding this.

Thank you all,
KK.


On Jan 18, 2008 10:11 PM, Wayne Pinette <Wpinette at tru.ca> wrote:
> Im sorry to say that the bug is  not in glibc, the bug is in your code/logic.
>
> fork() is doing exactly what it is suppose to do in this case, this is why:
>
>
> from man fork : The fork() function shall create a new proces.  The new process shall be an exact copy of the calling process...and so on.
>
> In your code :
>
> main()
> {
>         int a = 0;
>
>         while (1) {
>                 printf("XXX(%d)",++a);  <--- AT this point the buffer is not flushed, it is still full
>                 (void) sleep(1);
>                 if (fork() == 0) { <0---- at the point fork is called, the buffer is still not flushed, it is full
>                         printf("\n");  <-- at thsi point you flush the buffer, but you have flushed it off the first process, the copy has already been made, and was
>                                                     made with a full buffer.
>                         exit(0);
>                 }
>         }
> }
>
> If you put the "\n" in the original printf statement :
>
>  printf("XXX(%d)\n",++a);
>
> You will have flushed the buffer BEFORE the fork and consequently before the exact copy of the process, and it will work the way you want it to.
>
>
> Wayner
>
>
> >>> Dr Alan J Bartlett <stxsl_ajb at hotmail.com> 18/01/2008 8:21 am >>>
>
>
>
>
>
>
>
> KK,
>
> I am running CentOS 5, update 1 ( == RHEL 5.1) and thought I would mimic your test.
>
> $ uname -a
> Linux stxsl 2.6.18-53.1.4.el5.stxsl #1 SMP Tue Jan 8 21:29:57 GMT 2008 i686 i686 i386 GNU/Linux
> $ rpm -q glibc
> glibc-2.5-18.el5_1.1
> $ ldd zxc
>         linux-gate.so.1 =>  (0x00343000)
>         libc.so.6 => /lib/libc.so.6 (0x00b3d000)
>         /lib/ld-linux.so.2 (0x0016e000)
> $ cat zxc.c
> #include        <stdio.h>
> #include        <stdlib.h>
> #include        <unistd.h>
>
> main()
> {
>         int a = 0;
>
>         while (1) {
>                 printf("XXX(%d)",++a);
>                 (void) sleep(1);
>                 if (fork() == 0) {
>                         printf("\n");
>                         exit(0);
>                 }
>         }
> }
> $ ./zxc
> XXX(1)
> XXX(1)XXX(2)
> XXX(1)XXX(2)XXX(3)
> XXX(1)XXX(2)XXX(3)XXX(4)
> XXX(1)XXX(2)XXX(3)XXX(4)XXX(5)
> XXX(1)XXX(2)XXX(3)XXX(4)XXX(5)XXX(6)
>
> $
>
> You are not alone!
>
> Regards,
> Alan.
>
>
> _________________________________________________________________
> Free games, great prizes - get gaming at Gamesbox.
> http://www.searchgamesbox.com--
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
>
> https://www.redhat.com/mailman/listinfo/redhat-list
>