public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Laurent GUERBY <laurent@guerby.net>
To: gcc <gcc@gcc.gnu.org>, Paolo Bonzini <bonzini@gnu.org>
Cc: Arnaud Charlet <charlet@adacore.com>,
	Eric Botcazou <ebotcazou@adacore.com>
Subject: Need some Unix and /bin/sh expertise for GCC testsuite
Date: Fri, 14 Aug 2009 21:17:00 -0000	[thread overview]
Message-ID: <1250283155.20287.116.camel@localhost> (raw)

Hi,

Even after the last patch I can still see random ACATS failures on a
stock debian etch x86_64 machine (gcc13). I've added many traces to the
ACATS script and I can see now a common pattern and it's not related
to Ada multi threading or wrong code generation.

First the ACATS script itself is relatively straightforward: loop
over the test, copy some files, call gnatmake and then run the
compiled test and check the output.

The issue comes for a surprising - to me - /bin/sh behaviour,
if an /bin/sh expert could help me figure out the following:

=> gcc/testsuite/ada/acats/run_all.sh
<<
#!/bin/sh
# Run ACATS with the GNU Ada compiler
...
target_gnatmake () {
  echo gnatmake --GCC=\"$GCC\" $gnatflags $gccflags $* -largs $EXTERNAL_OBJECTS --GCC=\"$GCC\"
  gnatmake --GCC="$GCC" $gnatflags $gccflags $* -largs $EXTERNAL_OBJECTS --GCC="$GCC"
}
...
while ...
      ...
      target_gnatmake $extraflags -I$dir/support $main >> $dir/acats.log 2>&1
      if [ $? -ne 0 ]; then
         display "FAIL:	$i"
         failed="${failed}${i} "
         clean_dir
         continue
      fi

      echo "RUN $binmain" >> $dir/acats.log
      cd $dir/run

      ZSTAMP=none
      if [ ! -x $dir/tests/$chapter/$i/$binmain ]; then
         sync
         ZSTAMP=$(date '+%Y%m%dT%H%M%S')
         ls -l $dir/tests/$chapter/$i/ > /home/guerby/tmp/acats/postsync-${i}-${ZSTAMP} 2>&1
         ps fauxwwwww > /home/guerby/tmp/acats/psfauxw1-${i}-${ZSTAMP} 2>&1
      fi

      target_run $dir/tests/$chapter/$i/$binmain > $dir/tests/$chapter/$i/${i}.log 2>&1
      ...
>>

Now the common fail pattern is as follows:

1/ target_gnatmake succeeds, that is we don't pass in the first "if".

2/ However even is gnatmake has succeeded we enter the second "if"
because there's no executable in the dir as shown by "ls -l" output:

=> postsync-c48005b-20090813T202815
<<
total 44
-rw-r--r-- 1 guerby guerby 10345 2009-08-13 20:28 b~c48005b.adb
-rw-r--r-- 1 guerby guerby 12375 2009-08-13 20:28 b~c48005b.ads
-rw-r--r-- 1 guerby guerby  2786 2009-08-13 20:28 c48005b.adb
-rw-r--r-- 1 guerby guerby   784 2009-08-13 20:28 c48005b.ali
-rw-r--r-- 1 guerby guerby    12 2009-08-13 20:28 c48005b.lst
-rw-r--r-- 1 guerby guerby  3208 2009-08-13 20:28 c48005b.o
>>

3/ Here is the point I find surprising: the "ps fauxww" run in the
second "if" show that even if the script is fully sequential
at least one gnatmake subprocess (collect-ld) is still marked as running 
*in parallel* with the ps command in the subsequent "if" of the script!

=> psfauxw1-c48005b-20090813T202815
<<
...
guerby    7715  1.3  0.0  12176  1936 ?        SN   20:20   0:06   \_ /bin/sh /home/guerby/trunk/gcc/testsuite/ada/acats/run_all.sh
guerby    7794  0.0  0.0  10796  2476 ?        SN   20:28   0:00       \_ gnatmake --GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/ -gnatws -O2 -I/home/guerby/build/gcc/testsuite/ada/acats/support c48005b.adb -largs --GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/
guerby    7803  0.0  0.0   4048  1228 ?        SN   20:28   0:00       |   \_ /home/guerby/build/gcc/gnatlink c48005b.ali --GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/
guerby    7809  0.0  0.0   2880   584 ?        SN   20:28   0:00       |       \_ /home/guerby/build/gcc/xgcc b~c48005b.o ... -o c48005b ...
guerby    7810  0.0  0.0   2756   444 ?        SN   20:28   0:00       |           \_ /home/guerby/build/gcc/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o c48005b ...
guerby    7811  0.0  0.0  11548  1500 ?        RN   20:28   0:00       |               \_ /bin/sh /home/guerby/build/gcc/collect-ld --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o c48005b ....
guerby    7808  0.0  0.0  14328  1156 ?        RN   20:28   0:00       \_ ps fauxwwwww
...
>>

4/ we run the executable but since it's not there we get:

=> c48005b.log
<<
/home/guerby/trunk/gcc/testsuite/ada/acats/run_all.sh: line 16: /home/guerby/build/gcc/testsuite/ada/acats/tests/c4/c48005b/c48005b: Permission denied
>>

5/ After the run an empty file appears in another "ls -l" 
(not shown in the script above):

-rw-r--r-- 1 guerby guerby     0 2009-08-13 20:28 c48005b

6/ Waiting for one more second ("sleep 1" not shown above) the 
full file appears at last in "ls -l":

-rwxr-xr-x 1 guerby guerby 1164960 2009-08-13 20:28 c48005b

Any idea of why /bin/sh is running stuff in parallel instead
of sequential? 

Could some code in 
gnatmake/gnatlink/xgcc/collect2/collect-ld cause it?

guerby@gcc13:~$ /bin/sh --version
GNU bash, version 3.1.17(1)-release (x86_64-pc-linux-gnu)

Thanks in advance,

Laurent



             reply	other threads:[~2009-08-14 20:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-14 21:17 Laurent GUERBY [this message]
2009-08-14 21:32 ` Dave Korn
2009-08-14 21:37   ` Laurent GUERBY
2009-08-15  7:06     ` Dave Korn
2009-08-15 14:00       ` Laurent GUERBY
2009-08-14 21:43 ` Ralf Wildenhues
2009-08-14 22:57   ` Laurent GUERBY
2009-08-15  9:57     ` Ralf Wildenhues
2009-08-15 14:12       ` Laurent GUERBY
2009-08-15  0:24 ` Andreas Schwab
2009-08-15  4:11   ` Laurent GUERBY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1250283155.20287.116.camel@localhost \
    --to=laurent@guerby.net \
    --cc=bonzini@gnu.org \
    --cc=charlet@adacore.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).