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

[Will Schmidt]

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.log has:
> 
> 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
>