#49 EMMARuntimeException: stale metadata

[SeagullNL]

We are using EMMA for quite some time now, to do code
coverage in the Ant build of our Eclipse based product.
During this build, all files are created from scratch (so no
incremental instrumentation).

First we do the instrumentation:

emma.instrument:
[echo] Instrumenting...
[instr] processing instrumentation path ...
[instr] instrumentation path processed in 3686 ms
[instr] [1297 class(es) instrumented, 848 resource(s)
copied]
[instr] metadata merged into
[E:\Projects\BuildPuertoRicoDevB\build_dir\testing\legasuite
\coverage.metadata] {in 310 ms}
[copy] Copying 1 file to
E:\Projects\BuildPuertoRicoDevB\build_dir\testing\legasuite

This seems to work without problems and the file is in the
attached 'coverage.metadata'.

Then, for some 10 packages, we run our unit tests over the
instrumented classes (showing one of them):

junit:
[echo] Running
com.seagullsw.eclipse.core.resource.AllTests
[java] EMMA: collecting runtime coverage data ...
[java] EMMA: runtime controller started on port [47653]
[java] EMMA: locking coverage output file
[E:\Projects\BuildPuertoRicoDevB\build_dir\testing\legasuite
\com.seagullsw.eclipse.core.resource.test_coverage.ec] ...
[java] EMMA: runtime coverage data written to
[E:\Projects\BuildPuertoRicoDevB\build_dir\testing\legasuite
\com.seagullsw.eclipse.core.resource.test_coverage.ec] {in
120 ms}
[copy] Copying 1 file to
E:\Projects\BuildPuertoRicoDevB\build_dir\testing\legasuite
[style] Processing
E:\Projects\BuildPuertoRicoDevB\build_dir\testing\legasuite\ com.seagullsw.eclipse.core.resource.test_win32.xml to
E:\Projects\BuildPuertoRicoDevB\build_dir\testing\results\leg
asuite\xml\com.seagullsw.eclipse.core.resource.test_win32.x
ml
[style] Loading stylesheet
E:\Projects\BuildPuertoRicoDevB\build_dir\testing\legasuite\ CreatJUnitTestReportXml.xslt

This too seems to work without problems and the file is in
the
attached 'com.seagullsw.eclipse.core.resource.test_coverag
e.ec'.

Then, the results of all unit tests runs are merged and a
report is generated:

emma.instrument.report:
[echo] Generating instrumentation report...
[mkdir] Created dir:
E:\Projects\BuildPuertoRicoDevB\build_dir\testing\results\leg
asuite\emma
[mkdir] Created dir:
E:\Projects\BuildPuertoRicoDevB\build_dir\testing\results\leg
asuite\html\emma
[merge] processing input files ...
[merge] 10 file(s) read and merged in 191 ms
[merge] merged/compacted data written to
[E:\Projects\BuildPuertoRicoDevB\build_dir\testing\results\le
gasuite\emma\coverage.es] {in 921 ms}
[report] processing input files ...
[report] 1 file(s) read and merged in 100 ms
[report] com.vladium.emma.EMMARuntimeException:
[CLASS_STAMP_MISMATCH] runtime version of class
[com.seagullsw.eclipse.core.resource.AllTests] in the
coverage data is not consistent with the version of this class
in the metadata, possibly because stale metadata is being
used for report generation.
[report] at
com.vladium.emma.report.ReportDataModel.getView
(ReportDataModel.java:95)
[report] at
com.vladium.emma.report.AbstractReportGenerator.initialize
(AbstractReportGenerator.java:210)
[report] at
com.vladium.emma.report.txt.ReportGenerator.process
(ReportGenerator.java:64)
[report] at
com.vladium.emma.report.ReportProcessor._run
(ReportProcessor.java:255)
[report] at com.vladium.emma.Processor.run
(Processor.java:88)
[report] at com.vladium.emma.report.reportTask.execute
(reportTask.java:77)
[report] at com.vladium.emma.emmaTask.execute
(emmaTask.java:58)

Here, things go wrong…

The merged metadata is in the attached 'coverage.es'.

The exception mentions stale metadata because of an
inconsistency between the coverage data and the
metadata. This is strange, because both are created in one
build run.

We have the same results with EMMA version 'emma-
2.0.4217' and 'emma-stable-2.1.5320'.

Note: 'coverage.es' and 'coverage.metadata' are too large
to be attached (even zipped). Please supply means to
upload/email them.

[SeagullNL]

Coverage metadata of one package

[surveyor04]

Logged In: YES
user_id=1268059

I'm interested in a resolution to this issue as well... I
have been experiencing the same problem. The difference is
that I have been instrumenting classes and attempting to
compile reports via command line.
I create the jars, instrument them, and package into ear/sar
files for JBOSS deployment while on Windows. Instrumented
files are then ftp'd to JBOSS on Linux. Unit tests are run,
JBOSS killed, .em file ftp'd to the linux directory with the
.ec, and report run is attempted, but fails with the same
error message reported here.

[Vlad Roubtsov]

Logged In: YES
user_id=1013207

Unless we can reproduce this issue, we won't be able to fix
it. What we need is:

- the relevant *.ec and *.em (or *.es) files. If they are
too big, email them to my (vlad_r) SF alias.
- a sample *.class file that causes the problem

You also need to check that during your build you are not
accidently recompiling the same sources more than once. You
may be deleting stale EMMA files, but if you recompile after
you instrument the above can happen.

It would seem that you could help us even more by creating a
smaller reproducible testcase (how about narrowing
everything down just to the AllTests class?) and giving us
that instead of your entire project class set.