Regression: truncated I/O, probably after having spawned a lot of processes

[Thomas Schwinge]

Hi!

I have not yet gotten a chance to catch up with the last months worth of
Hurd development (but did notice that the "screen logout issue" is fixed,
hooray!), so please bear with me if this has already been discussed.

Said months of Hurd development have just found their way into my Hurd
system, in form of a Debian apt-get dist-upgrade, after having done the
last one in early summer.  As the recent one included a glibc 2.13 to
2.17 update as well as several other "heavy-weight" updates, I thought
it'd be a good idea to first sanity check the environment before getting
to what I originally wanted to do.  And, "of course", I didn't get that
far.  ;-)

Rebuilding the very same GCC sources that I built in June, I see only
expected changes in the build log (mostly related to the system glibc
update), but then, there are regressions in the test log (that particular
test run takes 10 h to complete...), for example:

     PASS: gcc.dg/cpp/pr33466.c  (test for errors, line 8)
     PASS: gcc.dg/cpp/pr33466.c  (test for errors, line 9)
     [...]
     PASS: gcc.dg/cpp/pr33466.c  (test for errors, line 50)
     PASS: gcc.dg/cpp/pr33466.c  (test for errors, line 51)
    -PASS: gcc.dg/cpp/pr33466.c  (test for errors, line 52)
    -PASS: gcc.dg/cpp/pr33466.c  (test for errors, line 53)
    -[...]
    -PASS: gcc.dg/cpp/pr33466.c  (test for errors, line 63)
    -PASS: gcc.dg/cpp/pr33466.c  (test for errors, line 64)
    +FAIL: gcc.dg/cpp/pr33466.c  (test for errors, line 52)
    +FAIL: gcc.dg/cpp/pr33466.c  (test for errors, line 53)
    +[...]
    +FAIL: gcc.dg/cpp/pr33466.c  (test for errors, line 63)
    +FAIL: gcc.dg/cpp/pr33466.c  (test for errors, line 64)
     PASS: gcc.dg/cpp/pr33466.c (test for excess errors)

Per the detailed log file, the problem is that the GCC stderr output ends
prematurely (this is checking the C preprocessor for generating the
expected error messages):

    Executing on host: [...]/gcc/xgcc -B[...]/gcc/ 
[...]/gcc/testsuite/gcc.dg/cpp/pr33466.c  -fno-diagnostics-show-caret 
-fdiagnostics-color=never   -std=gnu99 -S  -o pr33466.s    (timeout = 300)
    spawn [...]/gcc/xgcc -B[...]/gcc/ [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never -std=gnu99 -S -o pr33466.s
    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:8:18: error: invalid suffix "rh" 
on floating constant
    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:9:18: error: invalid suffix "rl" 
on floating constant
    [...]
    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:50:19: error: invalid suffix "ddw" 
on floating constant
    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:51:19: error: invalid suffix 
"ddcompiler exited with status 1

Notice the premature »compiler exited with status 1«, comparing to what I
get when running manually:

    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:8:18: error: invalid suffix "rh" 
on floating constant
    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:9:18: error: invalid suffix "rl" 
on floating constant
    [...]
    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:50:19: error: invalid suffix "ddw" 
on floating constant
    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:51:19: error: invalid suffix "ddq" 
on floating constant
    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:52:19: error: invalid suffix "ddl" 
on floating constant
    [...]
    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:63:19: error: invalid suffix "ddi" 
on floating constant
    [...]/gcc/testsuite/gcc.dg/cpp/pr33466.c:64:19: error: invalid suffix "idd" 
on floating constant

I have reproduced this problem, building GCC again from scratch, and
again running that part of the testsuite.

What the GCC testsuite (DejaGnu, runtest, expect, TCL) does, is spawning
a ton (10,000s) of GCC processes, one after the other, and looking at
their stdout/stderr, exit code, and output file(s) if applicable.

As the error does not occur when running the command manually, perhaps
there's some (new) leak that "accumulates" in the long-running test
harness process, and eventually causes this issue?  (Similar to the
<http://www.gnu.org/software/hurd/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.html>
issue we had before; still awaiting a proper fix...)

What I can't tell yet is whether the truncation happens at the sending
(GCC) or receiving (test harness) side.

On the console, I can see a lot of »task [...] deallocating an invalid
port 47, most probably a bug.« -- as I do not remember that from my test
runs half a year ago, perhaps that's related, too?

Pasting into wc the GCC output for a few different instances of this
issue, as present in the detailed log file, up to the premature »compiler
exited«, they all look pretty similar:

     44     349    5959
     39     344    5964
     35     381    5968
     36     379    5967
     34     377    5969

It generally seems to be happening after about 5960 characters of stderr
output.  Wait a moment -- add the sumer of lines again to the number of
characters ("\r\n" line ending?), and you'll get a constant number of
6003 -- huh.  (Maybe subtract one, because I manually added one line
break when pasting into wc.)

Any ideas where to begin looking?  I'll first try to come up with a
self-contained reproducer.  Somethink like in a loop popening that GCC
command, and compare the stderr output.


Grüße,
 Thomas

pgpO8gHE6v4n8.pgp
Description: PGP signature