[Bug go/52462] New: Several libgo tests FAIL intermittently: ../testdata races

[ro at gcc dot gnu.org]

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

             Bug #: 52462
           Summary: Several libgo tests FAIL intermittently: ../testdata
                    races
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
        AssignedTo: i...@airs.com
        ReportedBy: r...@gcc.gnu.org


I've seen several libgo testcases FAIL intermittently during highly parallel
bootstraps.  One example is

ln: creating symbolic link `../testdata/testdata': File exists
--- FAIL: flate.TestDeflateInflateString (0.24 seconds)
    ???:1: open ../testdata/e.txt: No such file or directory
    ???:1: open ../testdata/Mark.Twain-Tom.Sawyer.txt: No such file or
directory
FAIL
FAIL: compress/flate

I think I understand now what's going on: in testsuite/gotest, we have:

# Some tests refer to a ../testdata directory.
if test -e $srcdir/../testdata; then
  rm -f ../testdata
  abssrcdir=`cd $srcdir && pwd`
  ln -s $abssrcdir/../testdata ../testdata
fi

This construct is racy and inherently unreliable: if between the rm and ln -s
another gotest instance manages to create the ../testdata symlink, the ln -s
here will create its link inside the linked-to testdata directory in $srcdir,
writing into $srcdir which is not supposed to happen.  I've got instances of
this:

> pwd
/vol/gcc/src/hg/trunk/local/libgo/go
> ll -d */testdata/testdata
lrwxrwxrwx 1 ro gcc 62 Feb 24 18:42 compress/testdata/testdata ->
/vol/gcc/src/hg/trunk/local/libgo/go/compress/gzip/../testdata/
lrwxrwxrwx 1 ro gcc 62 Feb 24 20:58 html/testdata/testdata ->
/vol/gcc/src/hg/trunk/local/libgo/go/net/http/fcgi/../testdata/
lrwxrwxrwx 1 ro gcc 60 Feb 24 18:42 image/testdata/testdata ->
/vol/gcc/src/hg/trunk/local/libgo/go/image/color/../testdata/

Even if one replaced the rm/ln -s by a single ln -sf (no idea how portable 
that is), if between the creation of the link and its use another gotest
instance recreates it, pointing to a different directory, the failures occur
just the same.

This can only be avoided by not sharing ../testdata between different gotest
runs.  I see several possibilities:

* Replace ../testdata by testdata in the testcases.  I've no idea how this
  affects upstream libgo.

* Create an intermediate subdir in gotest$$.

* Use different directory names for testdata to avoid conflicts.

  Rainer