[Clam-devel] problems with running tests...

[Roman Goj]

Hi!

As promised I'm back with more problems (I can hear the loud cheers
even here in Poland! ;) ).

I've been afraid that the changes I'm making/will be making might
start breaking not only the code I'm working on, but also the
furthest, deepest parts of CLAM, my editor has never feasted upon...

So - I decided I needed to actually make everything work and compile
and all the tests to run smoothly. Until yesterday for example, some
tests would break because (I think) they needed something being built
with NetworkEditor, which here always failed to built, becasue I
haven't resolved my QTDIR issues...

Anyway - now everything compiles smoothly (though it seems my debian
unstable has some strange library names - i.e. I need to do ln -s
/usr/lib/libGL.so.1 /usr/lib/libGL.so, every time I restart my
computer... should I report all such system-specific problems? if only
for future reference for people having these problems? I haven't been
doing this so far, because it mostly seems to be debian's (or my own
rather more likely ;-) )  fault... after all *unstable* isn't in the
name for nothing, heh...), but tests are failing... and I couldn't
figure out why (I also keep updating the test data repository).

So: the problem I'm having is:
UnitTests compile nicely, the list of tests is displayed as usually...
but then it just stops. Running gdb and then valgrind, I figured the
culprit to be this line of code:
reader.Do(buf); in
CLAM/test/UnitTests/DescriptorsTests/AudioDescriptorsTest.cxx (see
attached patch, which comments it out, I'm running the tests using
this patch :( )...
... even though there are no errors mentioned by gdb/valgrind, it's
just that this function takes most time (callgrind file attached).
(also issued callgrind_control -b to check what function it's running
when it hung)
I actually can't figure out what's wrong - the worst thing is that the
loop in which reader.Do(buf) is called, never seems to stop:

reader.Start();
do {
	reader.Do(buf);
} while (!reader.Done());
reader.Stop();

and so, there aren't even any errors displayed, no segfaults, nothing,
and yet it keeps taking lots of cpu...

Also - since today morning (no changes made to the code, only svn up),
FunctionalTests are also broken, I get this:

# QUOTE

!!!FAILURES!!!
Test Results:
Run:  100   Failures: 0   Errors: 1


1) test: CLAMTest::MultiChannelAudioFileReaderFunctionalTest::test_MpegAudioFiles_192kbps_44kHz_AreDecoded_OK
(E)
uncaught exception of type CLAM::ErrAssertionFailed
- Starting an unconfigured processing

# END OF QUOTE

I'm not sure this has anything to do with the problems, but I guess it
may have, since it's a major change to the system, I had to upgrade
libc6 (now at 2.6.5) to get some packages I needed lately to
compile... (like fftw2, which I actually didn't have and that broke
some tests (I've been using only fftw3 for some time now) ) ...which
had depends on the libc6 upgrade. I hear it's generally a thing to
avoid - upgrading libc6 - so - maybe that's the problem...? I'd really
like to avoid downgrading now though (hunting down the older packages,
all the ones I might need, would be a nightmare...). I'm mentioning
this because I never had these problems with UnitTests before
(unfortunately I don't remember whether I ran them lately before the
upgrade), there were some tests broken, true, but at least it never
hang up on me...

So - I'm attaching a patch with the problem commented out and also the
callgrind file (as proof that there's something wrong). Do you know
what my problems might be? I didn't try doing anything to the code -
since testfarm is green, I guess the code itself must be ok...

Sorry for another long post, heh... (and not a very pleasant one at
that :( I'd prefer to write long posts... because of the long lists of
successes ;-) but this will come! )

roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: This-code-breaks-my-UnitTests.patch
Type: text/x-diff
Size: 546 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20070803/6c0d2be5/attachment-0004.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callgrind.out.6068.2
Type: application/octet-stream
Size: 6049 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20070803/6c0d2be5/attachment-0004.obj>