Debian Bug report logs - #23560
libc6: fork() corrupts libc6 buffers

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: <tbittih@pal.xgw.fi>

To: submit@bugs.debian.org

Subject: libc6: fork() corrupts libc6 buffers

Date: Mon, 15 Jun 1998 23:13:56 +0300 (EEST)

Package: libc6
Version: 2.0.7pre1-4

fork() seems to be corrupting memory... hits fgets() buffers for example...
will send an example program right when I get the bug # back ;)

-- System Information
Debian Release: 2.0
Kernel Version: Linux bx1 2.1.106 #4 Sun Jun 14 12:22:10 EEST 1998 i586 unknown

Versions of the packages libc6 depends on:
ii  ldso            1.9.9-1        The Linux dynamic linker, library and utilit

Message #10 received at 23560@bugs.debian.org (full text, mbox, reply):

From: <tbittih@pal.xgw.fi>

To: 23560@bugs.debian.org

Subject: Here's one simplified program where the bug appears...

Date: Mon, 15 Jun 1998 21:00:46 +0000 (GMT)

[Message part 1 (text/plain, inline)]

... if you rip out all the if(fork()<1)exit(0);'s then the program will
not print out "BUG" ... it won't print that either if you compile it with
libc5 ... so I guess this is a libc6 bug ...

[debug.tar.gz (application/x-gzip, inline)]

Message #15 received at 23560@bugs.debian.org (full text, mbox, reply):

From: Dale Scheetz <dwarf@polaris.net>

To: tbittih@pal.xgw.fi, 23560@bugs.debian.org

Subject: Re: Bug#23560: libc6: fork() corrupts libc6 buffers

Date: Mon, 15 Jun 1998 17:11:49 -0400 (EDT)

On Mon, 15 Jun 1998 tbittih@pal.xgw.fi wrote:

> Package: libc6
> Version: 2.0.7pre1-4
> 
> fork() seems to be corrupting memory... hits fgets() buffers for example...
> will send an example program right when I get the bug # back ;)
> 
Please also try the 2.0.7pre3-1 that is slink? It has many fixes that
aren't in pre1. These fixes will be appearing in frozen shortly in the
final 2.0.7 release.

Thanks,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-

Message #20 received at 23560@bugs.debian.org (full text, mbox, reply):

From: Tuomas Heino <tbittih@xgw.fi>

To: Dale Scheetz <dwarf@polaris.net>

Cc: 23560@bugs.debian.org

Subject: Re: Bug#23560: libc6: fork() corrupts libc6 buffers

Date: Tue, 16 Jun 1998 01:09:17 +0300 (EET DST)

On Mon, 15 Jun 1998, Dale Scheetz wrote:

> On Mon, 15 Jun 1998 tbittih@pal.xgw.fi wrote:
> 
> > Package: libc6
> > Version: 2.0.7pre1-4
> > 
> > fork() seems to be corrupting memory... hits fgets() buffers for example...
> > will send an example program right when I get the bug # back ;)
> > 
> Please also try the 2.0.7pre3-1 that is slink? It has many fixes that
> aren't in pre1. These fixes will be appearing in frozen shortly in the
> final 2.0.7 release.
> 
Yes the bug exists in 2.0.7pre3-1 too... the test program should have 
reached you by now ;)

Message #25 received at 23560@bugs.debian.org (full text, mbox, reply):

From: tbittih@pal.xgw.fi

To: linux-kernel@vger.rutgers.edu

Cc: 23560@bugs.debian.org

Subject: fork() memory corruption... is this glibc2 or kernel?

Date: Sat, 20 Jun 1998 21:46:49 +0000 (GMT)

[Message part 1 (text/plain, inline)]

While coding some network apps I noticed that fork() seemed to corrupt
memory... so I ripped 95% of the program out and changed some things so
that the bug hit the "critical" memory area around 10x more frequently...
I'd want to know whether this can be seen with libc's other than
2.0.7pre1/2.0.7pre3... and arch's other than x86...
... and after that I'd want to get rid of this bug for good ;)

[fork_debug.tar.gz (application/x-gzip, inline)]

Message #30 received at 23560@bugs.debian.org (full text, mbox, reply):

From: MOLNAR Ingo <mingo@valerie.inf.elte.hu>

To: tbittih@pal.xgw.fi

Cc: linux-kernel@vger.rutgers.edu, 23560@bugs.debian.org

Subject: Re: fork() memory corruption... is this glibc2 or kernel?

Date: Sun, 21 Jun 1998 05:59:43 +0200 (MET DST)

On Sat, 20 Jun 1998 tbittih@pal.xgw.fi wrote:

> While coding some network apps I noticed that fork() seemed to corrupt
> memory... so I ripped 95% of the program out and changed some things so
> that the bug hit the "critical" memory area around 10x more frequently...

the subtle issue here is that you are using libc6's fgets(), which uses
mmap(), which is not copied on fork() ... this way you might see the
changes done in a child/parent process.

(also, you check for erroneous fork()s in a broken way, fork returns -1 on
error, not 0.) 

-- mingo

Message #35 received at 23560@bugs.debian.org (full text, mbox, reply):

From: MOLNAR Ingo <mingo@valerie.inf.elte.hu>

To: tbittih@pal.xgw.fi

Cc: linux-kernel@vger.rutgers.edu, 23560@bugs.debian.org

Subject: Re: fork() memory corruption... is this glibc2 or kernel?

Date: Sun, 21 Jun 1998 06:13:23 +0200 (MET DST)

On Sun, 21 Jun 1998, i wrote:

> the subtle issue here is that you are using libc6's fgets(), which uses
> mmap() [...]

uhm, it does not. boggle.

-- mingo

Message #40 received at 23560@bugs.debian.org (full text, mbox, reply):

From: Tuomas Heino <tbittih@xgw.fi>

To: MOLNAR Ingo <mingo@valerie.inf.elte.hu>

Cc: linux-kernel@vger.rutgers.edu, 23560@bugs.debian.org

Subject: Re: fork() memory corruption... is this glibc2 or kernel?

Date: Sun, 21 Jun 1998 11:36:24 +0300 (EET DST)

On Sun, 21 Jun 1998, MOLNAR Ingo wrote:
 
[snip]
>
> (also, you check for erroneous fork()s in a broken way, fork returns -1 on error, not 0.)
>
well I guess you already figured this out but I think I should say it so
the others get it too: that's an oversimplification to exit(-1) the 
parent on error and exit(0) the child in right after it has started...
 
On Sun, 21 Jun 1998, MOLNAR Ingo wrote:
 
[snip]
> 
> i think the bug is a bit more complex. The actual 'corruption' is
> reproducible no matter what the standard output is.
> 
> the 'secret' shared space between forked child and parent is the open
> file's offset. If the child does an lseek() on fd, it changes it in the
> parent too. The corruption magically goes away if you change the exit()
> call to _exit(). since the 'main process' uses fgets, it depends on the
> file offset. exit() tries to change the offset under libc6, and
> occasionally messes it up for the parent. Normally one wouldnt notice this
> bug. 
> 
> so this looks like a libc6 bug. It's not 'memory corruption' actually, but
> 'messed up file offset', which results in random file offsets, and
> sometimes this means the 'BUGBUG' part of the file.
> 
or libc* ? as in if stdout is a file then the the _first_ fork()/exit() 
pair causes noticeable 'corruption' with both libc5 & libc6...
now... which part of exit() is messing up the offset?

and how 'safe' is it to use fflush(NULL); _exit(0); instead of exit(0); ?
as in 'the real program' (network db mirror app) uses pipe(); fork(); dup2();
to pipe the stdout/stderr of the children to the parent for delayed output...
do pipe()s need fflushing or not? 

... now where should we send this message? as in if it's a libc* bug ...

Message #45 received at 23560@bugs.debian.org (full text, mbox, reply):

From: Tuomas Heino <tbittih@xgw.fi>

To: Roderich Schupp <rsch@ExperTeam.de>

Cc: linux-kernel@vger.rutgers.edu, adam@cfar.umd.edu, 23560@bugs.debian.org

Subject: Re: fork() memory corruption... is this glibc2 or kernel?

Date: Mon, 22 Jun 1998 00:21:10 +0300 (EET DST)

On Sun, 21 Jun 1998, Roderich Schupp wrote:

>   Note that after a fork(), two handles exist where one existed
>   before. The application must assure that, if both handles will ever be
>   accessed, that they will both be in a state where the other could
>   become the active handle first. The application must prepare for a
>   fork() exactly as if it were a change of active handle. (If the only
>   action performed by one of the processes is one of the exec functions
>   or _exit() (not exit()), the handle is never accessed in that
>   process.)
[snip]
now is there a way to do most of the exit() stuff easily and skip things 
that break things up? ;)
> 
> That is, glibc is correct and the bug is in your program. And
> issuing a fflush() before the fork() is the correct fix.
> 
Nope makes absolutely no diff... the stream which's file position is 
getting corrupted is an INPUT stream, not output; therefore fflush() 
won't have any effect on it...
child's exit() seems to be messing parent's _input_ stream position...
now this test program can avoid the bug by using _exit() instead of exit()...
... but as the network db mirror thingie I'm writing might be using 
atexit and alike without me even knowing about that I reallly can't just 
exit the children with "fflush(NULL); _exit(code);" ... Well I'll reread 
all the (missing?) documentation I can find on this thing ...

Hmm how offtopic is this for linux-kernel? (... _if_ there isn't anything 
wrong with the kernel that is...)

-_-
the children are supposed to 
dup2(child[id].out[1]), STDOUT_FILENO); where out is from a pipe() 
created by the parent... how to do that safely if the related things are 
full of boobytraps? (the code seems to work but...)

Message #50 received at 23560@bugs.debian.org (full text, mbox, reply):

From: Tuomas Heino <tbittih@xgw.fi>

To: linux-kernel@vger.rutgers.edu, 23560@bugs.debian.org

Cc: Adam Sulmicki <adam@cfar.umd.edu>, Roderich Schupp <rsch@ExperTeam.de>

Subject: Re: fork() memory corruption - PATCH for glibc2 (was Re: fork() memory corruption... is this glibc2 or kernel?)

Date: Mon, 22 Jun 1998 13:17:19 +0300 (EET DST)

I think I found it... any comments on the following patch?

--- src/glibc-2.0.7pre3/libio/genops.c     Fri Apr 18 02:21:30 1997
+++ genops.c.fixed      Mon Jun 22 13:07:04 1998
@@ -619,16 +619,21 @@
       _IO_OVERFLOW (fp, EOF);
 }

+/*
+ * 1998-06-22 / Tuomas Heino <tbittih@pal.xgw.fi>:
+ * _IO_SETBUF (fp, NULL,0) breaks parent process's stdin
+ * ... only _IO_cleanup seems to be calling unbuffer_all ... let's rename it
+ */
 void
-DEFUN_VOID(_IO_unbuffer_all)
+DEFUN_VOID(_IO_unbuffer_all_except_input)
 {
   _IO_FILE *fp;
   for (fp = _IO_list_all; fp != NULL; fp = fp->_chain)
-    if (! (fp->_flags & _IO_UNBUFFERED))
+    if (! (fp->_flags & (_IO_UNBUFFERED|_IO_NO_WRITES)))
       _IO_SETBUF (fp, NULL, 0);
 }

-void
+void
 DEFUN_VOID(_IO_cleanup)
 {
   _IO_flush_all ();
@@ -640,7 +645,7 @@

      The following will make the standard streambufs be unbuffered,
      which forces any output from late destructors to be written out. */
-  _IO_unbuffer_all ();
+  _IO_unbuffer_all_except_input ();
 }

 void

Send a report that this bug log contains spam.