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
next 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).