Re: bug in glibc?
- From: krishnaakishore@xxxxxxxxx
- Date: Fri, 18 Jan 2008 22:52:05 +0530
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@xxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
- References:
- bug in glibc?
- From: krishnaakishore
- RE: bug in glibc?
- From: Dr Alan J Bartlett
- RE: bug in glibc?
- From: Wayne Pinette
- bug in glibc?
- Prev by Date: RE: bug in glibc?
- Next by Date: Re: Out of Memory issue (was: redhat-list Digest, Vol 47, Issue 16)
- Previous by thread: RE: bug in glibc?
- Next by thread: Re: bug in glibc?
- Index(es):
Relevant Pages
|