ClamAV problem on ppc64 buildbot. Was: Re: ppc64 clang LNT buildbot / reference_output / test failures

[Renato Golin]

Hi Will,

No, I haven't looked into that since the release process started. I will
once it's all finished, but I don't think there's anything to do with how
the directories are scanned.

It seems that the order comes up from exploding a packed file, but I've
added a sort into that packed file and the order is still different.

ClamAV is an old program, and I'm not sure what's the benefit of running
it, if there's anything special about it, but I wouldn't mind disabling
some functionality to avoid random output.

cheers,
--renato


On 4 June 2013 21:29, Will Schmidt <will_schmidt at vnet.ibm.com> wrote:

> On Wed, 2013-05-08 at 11:16 -0500, Hal Finkel wrote:
> > Renato,
> >
> > We're now seeing a new problem with the ClamAV test. This problem does
> not seem to show up if you run the test-suite from the command line, but
> only when run through LNT (although this could obviously mean many things).
>
> Hi Renato, Hal,
>   Have either of you made any headway on the clamAV issue on ppc64?  I
> cleared up the directories on the buildbot this morning, to verify we
> aren't running with any old code, and see the issue remains.
>
> http://fpaste.org/16559/37707613/
>
> The gist of the issue is that the "Matched signature for file type..."
> messages are appearing out of order.
>
> I did look for a 'scanned directories' reference that was mentioned
> earlier, and that content seems consistent between .out-nat
> and .out-simple.
>
> clamscan.out-nat:Scanned directories: 0
> clamscan.out-nat:Scanned files: 16
> clamscan.out-simple:Scanned directories: 0
> clamscan.out-simple:Scanned files: 16
>
>
> Thanks,
> -Will
>
>
>
>
> >
> >
> http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux/builds/2793/steps/lnt.nightly-test/logs/test.loghas:
> >
> > cp /home/clangbuild/clang-ppc64-1/test-suite/instant.txt
> Output/clamscan.out-nat.time
> > /home/clangbuild/clang-ppc64-1/test-suite/DiffOutput.sh "diff " simple
> clamscan
> > ******************** TEST (simple) 'clamscan' FAILED!
> ********************
> > Execution Context Diff:
> > 1304,1305d1303
> > < Matched signature for file type %s
> > <
> > 1372a1371,1372
> > > Matched signature for file type %s
> > >
> > 1693,1694d1692
> > < Matched signature for file type %s
> > <
> > 1761a1760,1761
> > > Matched signature for file type %s
> > >
> > 1965,1966d1964
> > < Matched signature for file type %s
> > <
> > 2033a2032,2033
> > > Matched signature for file type %s
> > >
> > 2321,2322d2320
> > < Matched signature for file type %s
> > <
> > 2388a2387,2388
> > >
> > > Matched signature for file type %s
> >
> > So these 'Matched signature' lines are appearing out of order somehow.
> Will put the diff -u here: http://fpaste.org/10881/79449211/
> >
> > Do you have any idea what could cause this?
> >
> > Thanks again,
> > Hal
> >
> > ----- Original Message -----
> > >
> > > On 26 April 2013 15:15, Hal Finkel < hfinkel at anl.gov > wrote:
> > >
> > >
> > >
> > >
> > >
> > > I ran svn update (in the test suite directory) yesterday. It was
> > > missing only r180566, and that test (pcompress2) was fine. Running
> > > svn diff reports no local changes. diffing the
> > > MultiSource/Applications/ ClamAV/Output/clamscan.out-nat with
> > > llvm-trunk/projects/test- suite/MultiSource/
> > > Applications/ClamAV/clamscan. reference_output reports no
> > > differences.
> > >
> > >
> > > Your out-nat is correct, what's weird is your out-simple. It's as it
> > > would be on the old code, without sorting, as if you got the updated
> > > reference output but not the updated source code... Ex:
> > >
> > >
> > > 2955c2957
> > >
> > >
> > > < Scanned directories: 1
> > > ---
> > > > Scanned directories: 0
> > >
> > >
> > > Currently, no directories are scanned because the code first
> > > retrieves the list of files (recursively), sorts them, and then
> > > scans, it doesn't scan any dir, only specific files. The old code
> > > used to...
> > >
> > >
> > > --renato
> > >
> > >
> > > PS: This is another source of randomness, the order in which inodes
> > > appear in a directory, but it was supposedly all removed, and
> > > definitely on ClamAV.
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130604/8ed0533f/attachment.html>