|
From: Julian S. <js...@ac...> - 2011-10-07 13:47:27
|
It's great to see the regtests getting fixed up.
Relatedly .. if you add/remove/rename svn-tracked files
(in this case, the various expected-output files), please be sure
to update EXTRA_DIST in the associated Makefile.am. If that
doesn't happen then either
(a) "make dist" (building the tarball) fails, or
(b) make dist works, but running regression tests from a
tarball fails, because files are missing, or
(c) running regression tests from a tarball falsely causes some tests
on some platforms to fail when the same from-svn-tree would succeed,
because the necessary special-case .exp files are missing.
(c) is particularly scary, because it's invisible most of the time.
I just tried running 'make dist', and it fails with
make[2]: *** No rule to make target `badjump.stderr.exp-s390x', needed by
`distdir'. Stop.
Looking back over the commits of the past few days, I see the following
which added/removed/renamed files, but have no Makefile.am changes:
12107 12103 12098 12097 12092 12091 12079 12077
I'll try to get the EXTRA_DISTs back in sync over the next few days.
J
On Thursday, October 06, 2011, Florian Krohm wrote:
> Here is an update on the regression tests. If you're on cc I'm
> asking for your help.
>
> Not included in the table are those failing testcases for which
> we have immediate fixes pending.
>
> I use these abbreviations for distributions:
> U10 = Ubuntu 10.10
> F.. = Fedora ..
> S11 = SLES 11
> R4 = RHEL 4
> 2.6.37 = Rich Coe's run. I don't know what distribution he's using.
>
> The x86 results are from running on my thinkpad.
>
>
> x86 x86_64 s390x
> --- ------------------------- --------
> memcheck
> origin5-bz2 F15 F14 2.6.37
> overlap F15
> linux/stack_switch F14 F13 F11 2.6.37
> long_namespace_xml F11
> linux/timerfd-syscall F S11
> manuel3 R4
> partial_load_ok R4
> varinfo6 R4
>
> helgrind
> hg05_race2 F15
> pth_barrier3 F13
> tc18_semabuse F S11 R4
> tc20_verifywrap F S11 R4
> tc09_bad_unlock R4
> tc14_laog_dinphils R4
> tc23_bogus_condwait U10
>
> drd
> tc04_free_lock F S11 R4
> tc09_bad_unlock F S11 R4
> tc23_bogus_condwait U10
>
> gdbserver_tests
> mcbreak F14
> mcclean_after_fork F14
> mcinfcallWSRU F14
> mcleak F14
> mcmain_pic F14
> mcvabits F14
> mssnapshot F14 2.6.37
> nlpasssigalrm F14
> nlsigvgdb F14
>
>
> Here are some comments about the non-s390x specific testcases:
>
> memcheck / overlap
> Julian suspects it's related to the changes in handling memcpy,
> memmove that went in a few weeks ago.
> My plan is to filter this out, unless somebody has a better suggestion.
>
> memcheck / origin5-bz2
> There are different answers about the origin of an uninitialized
> value. On some systems it's said to come from dynamically allocated
> memory whereas it seems it ought to come from a client request.
>
> memcheck / linux / stackswitch
> Could be related to the system wrapper for the clone call or to
> our less than ideal handling of stack switches.
>
> memcheck / long_namespace_xml
> Looks like a real bug to me.
>
> helgrind / hg05_race2
> Related to DWARF reading. Julian thinks this will be difficult to fix
> in the current dwarf3 framework
>
> helgrind / pth_barrier3
> There are extra error messages. Needs investigation
>
> helgrind / tc23_bogus_condwait
> drd / tc23_bogus_condwait
> Most likely harmless. A different error is issued on x86 perhaps related
> to 32 bit vs 64 bit.
>
> helgrind / tc08_hbl2
> helgrind / annotate_hbefore
> Intermittent fasilures and hangs.
> It is suspected that these are due to memory contention issues.
> May require inserting memory fences in the testcase in strategic places
> to get deterministic behaviour.
>
>
> Here is where I'm asking for help:
>
> Tom, could you check in an exp file for this test:
>
> none
> shell F15
>
> I would do it myself but I do not know what shell it is. So I cannot
> pick a meaningful name for the exp file.
>
> On Fedora 14 the gdbserver tests are failing. Perhaps this is as easy
> to fix as
> yum --disablerepo='*' --enablerepo='*-debuginfo' install .....
> ?
>
> Julian said he will check in a 2nd set of exp files for these:
>
> none:
> amd64/bug132918 F11 F9
> amd64/fxtract F11 F9
> amd64/sse4-64 F11 F9
> x86/fxtract F11 F9
>
> ARM result would be good, too.
>
>
> Rich: Could you update your nightly build machinery such that it
> uses the latest version of the nightly script? That would
> show us what kind of system you are running.
>
> Maynard: can you run a ppc regtest and tar up the diffs and send them
> to me. I'd like to see how we're doing there WRT filtering backtrace
> noise.
>
> Thanks,
> Florian
|