This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug go/52462] New: Several libgo tests FAIL intermittently: ../testdata races
- From: "ro at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 02 Mar 2012 14:22:59 +0000
- Subject: [Bug go/52462] New: Several libgo tests FAIL intermittently: ../testdata races
- Auto-submitted: auto-generated
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: ian@airs.com
ReportedBy: ro@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