You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by siddharth srivastava <ak...@gmail.com> on 2012/04/14 03:14:23 UTC

Emma report generation fails

Hi

I have been trying to generate code coverage report(suites.All) with
Emma. I was
able to instrument the jar files and run the test cases. But the report
generation fails with the following error:

java.io.UTFDataFormatException: malformed input around byte 52
        at java.io.DataInputStream.readUTF(Unknown Source)
        at java.io.DataInputStream.readUTF(Unknown Source)
        at com.vladium.emma.data.ClassDescriptor.readExternal(ClassDescriptor.ja
va:171)
        at com.vladium.emma.data.MetaData.readExternal(MetaData.java:228)
        at com.vladium.emma.data.DataFactory.readEntry(DataFactory.java:770)
        at com.vladium.emma.data.DataFactory.mergeload(DataFactory.java:461)
        at com.vladium.emma.data.DataFactory.load(DataFactory.java:56)
        at com.vladium.emma.report.ReportProcessor._run(ReportProcessor.java:175
)
        at com.vladium.emma.Processor.run(Processor.java:54)
        at com.vladium.emma.report.reportCommand.run(reportCommand.java:130)
        at emma.main(emma.java:40)

I see that Knut also faced this error earlier,
http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/93262

Has there been a workaround for this ?

-- 
Regards
Siddharth Srivastava

Re: Emma report generation fails

Posted by Knut Anders Hatlen <kn...@oracle.com>.
siddharth srivastava <ak...@gmail.com> writes:

> Hi
>
> I have been trying to generate code coverage report(suites.All) with
> Emma. I was
> able to instrument the jar files and run the test cases. But the report
> generation fails with the following error:
>
> java.io.UTFDataFormatException: malformed input around byte 52
>         at java.io.DataInputStream.readUTF(Unknown Source)
>         at java.io.DataInputStream.readUTF(Unknown Source)
>         at com.vladium.emma.data.ClassDescriptor.readExternal(ClassDescriptor.ja
> va:171)
>         at com.vladium.emma.data.MetaData.readExternal(MetaData.java:228)
>         at com.vladium.emma.data.DataFactory.readEntry(DataFactory.java:770)
>         at com.vladium.emma.data.DataFactory.mergeload(DataFactory.java:461)
>         at com.vladium.emma.data.DataFactory.load(DataFactory.java:56)
>         at com.vladium.emma.report.ReportProcessor._run(ReportProcessor.java:175
> )
>         at com.vladium.emma.Processor.run(Processor.java:54)
>         at com.vladium.emma.report.reportCommand.run(reportCommand.java:130)
>         at emma.main(emma.java:40)
>
> I see that Knut also faced this error earlier,
> http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/93262
>
> Has there been a workaround for this ?

I haven't investigated it further, but it still happens every other day
(on average) in a nightly job I have running in my environment.

I suspect that it is caused by one of the tests that spawn new Java
processes, and that the spawned processes write coverage data
concurrently and somehow end up corrupting the file for each other if
the timing is right.

-- 
Knut Anders

Re: Emma report generation fails

Posted by Bryan Pendleton <bp...@gmail.com>.
> able to instrument the jar files and run the test cases. But the report
> generation fails with the following error:
>
> java.io.UTFDataFormatException: malformed input around byte 52
>          at java.io.DataInputStream.readUTF(Unknown Source)
>          at java.io.DataInputStream.readUTF(Unknown Source)
>          at com.vladium.emma.data.ClassDescriptor.readExternal(ClassDescriptor.ja
>
> I see that Knut also faced this error earlier,
> http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/93262

I don't know what's wrong, sorry.

Here's a couple possibilities that we could try to rule out:

1) Perhaps you are running the tests with SANE jars but then running
the code coverage reports with INSANE jars (or vice versa)?

2) Perhaps some of the tests run with JDK 1.4, some with JDK 1.5, some with
JDK 1.6, and that usage of differing JDKs in the test runs is confusing the
EMMA classfile reader?

3) Perhaps there is a resource problem, like EMMA is running out of
memory during the analysis, and this is just a misleading way of reporting
the out-of-resources problem

4) Perhaps the captured coverage information from the test runs got
damaged during the run, like maybe a test crashed while running and
so it corrupted the coverage database, or the disk filled up while the
test was running and corrupted the coverage database?

One thing to try might be to run a smaller set of tests. Rather than
running ALL the test suites, which is a LOT of tests, start by verifying
that you can just run a small test suite with EMMA coverage enabled,
and we can work the kinks out of the process in a smaller setting.

thanks,

bryan