[Bug libstdc++/56016] New: mutlithreading problem with iostream

[Bug libstdc++/56016] New: mutlithreading problem with iostream

[bugs at justexpired dot e4ward.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56016

             Bug #: 56016
           Summary: mutlithreading problem with iostream
    Classification: Unclassified
           Product: gcc
           Version: 4.6.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bugs@justexpired.e4ward.com


Created attachment 29188
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29188
sample program

I wrote a program that uses 2 threads (pthreads), one to read from stdin, the
other to write to stdout. The goal is that even if stdout is blocked by a pipe,
reading from stdin should not be blocked, instead, data should be accumulated
in the program's heap and eventually copied to stdout. The program works fine
if reading and writing are done with unistd (read/write) or cstdlib
(fread/fwrite) routines, but not with iostream (cin.read/cout.write).

I'm using stock Linux Mint 13, which comes with gcc 4.6.3.

The program is attached, I compiled it with:
$ g++ -g -o drain drain.cpp -lpthread

To reproduce the bug, follow these steps:

1. Create an input file:
$ dd if=/dev/zero bs=1024 count=256 >zeros

2. Create 2 named pipes:
$ mkfifo pipe-1
$ mkfifo pipe-2

3. Start a source and a sink:
$ cat zeros >pipe-1 &
$ { sleep 3000000; cat >result; } <pipe-2 &

4. Finally, connect them with our program:
$ ./drain 2 <pipe-1 >pipe-2 &

Expected behaviour: job 1 (cat into pipe-1) should finish right away, with all
input transferred to the buffers of ./drain. The output thread of ./drain
should be blocked, waiting for somebody to read data from pipe-2. To cause the
entire pipeline to complete, kill the sleep process with e.g.
$ killall sleep
This causes the cat in the sink to pull data from pipe-2.

The expected behaviour occurs when using ./drain 0 (unistd routines) or ./drain
1 (cstdlib routines), but not with ./drain 2 (iostream routines)

Observed behaviour: (most of the time...) job 1 doesn't complete. Instead, the
input thread of ./drain blocks at some point, without completing the stdin
reading. When the sleep process is killed, the entire pipeline completes. The
problem is the blocking, though. Perhaps the blocked cout.write() holds some
mutex, preventing cin.read() from completing. But I'm speculating here.

Note: the named pipes have a certain capacity, in my case about 65536. This
means the output thread of ./drain will be able to write a few blocks even
before the sleep process ends and cat reads from pipe-2. For the same reason,
the cat into pipe-1 might complete even if the input thread of ./drain blocks
(which is the bad behaviour), as long as the difference can be held by pipe-1.
The numbers make the bug reproducible on my system, but if the pipes have
larger capacity, the size of the input should be increased.

[Bug libstdc++/56016] mutlithreading problem with iostream

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56016

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-17 09:16:20 UTC ---
You might need std::ios_base::sync_with_stdio(false);

[Bug libstdc++/56016] mutlithreading problem with iostream

[bugs at justexpired dot e4ward.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56016

--- Comment #2 from JxP <bugs at justexpired dot e4ward.com> 2013-01-17 17:24:52 UTC ---
Created attachment 29195
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29195
sample program not mixing iostream with stdio

I confirm that using ios_base::sync_with_stdio(false) makes the original
program run correctly (use argument 3 for that).

However, I would expect that after commenting out all fprintf(stderr) lines,
the program should work correctly even without that extra command (still use
argument 2 for that), because then it doesn't explicitly use any stdio
routines. But it doesn't. To see it fail now that we don't trace steps on
stderr, follow the steps in the original post, use argument 2, then at the end
type jobs to see the first cat still running.

Why would the user be expected to ask iostream not to sync with stdio, if stdio
isn't used?!

[Bug libstdc++/56016] mutlithreading problem with iostream

[bugs at justexpired dot e4ward.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56016

--- Comment #3 from JxP <bugs at justexpired dot e4ward.com> 2013-01-17 17:45:24 UTC ---
Created attachment 29196
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29196
sample program using iostream onlywith stdio

[Bug libstdc++/56016] mutlithreading problem with iostream

[bugs at justexpired dot e4ward.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56016

--- Comment #4 from JxP <bugs at justexpired dot e4ward.com> 2013-01-17 17:51:53 UTC ---
Comment on attachment 29196
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29196
sample program using iostream only

This last one doesn't even include cstdio or unistd.h. Still,
ios_base::sync_with_stdio makes the difference between working correctly or
not.