I ran code coverage with emma, and finally I could not generate the report because of the following exception:
java.io.UTFDataFormatException: malformed input around byte 27
at java.io.DataInputStream.readUTF(DataInputStream.java:656)
at java.io.DataInputStream.readUTF(DataInputStream.java:564)
at com.vladium.emma.data.MetaData.readExternal(MetaData.java:235)
at com.vladium.emma.data.DataFactory.readEntry(DataFactory.java:734)
at com.vladium.emma.data.DataFactory.mergeload(DataFactory.java:426)
at com.vladium.emma.data.DataFactory.load(DataFactory.java:56)
at com.vladium.emma.report.ReportProcessor._run(ReportProcessor.java:176
Note that:
1) the file being processed is coverage data rather than a metadata file
2) the coverage data file contains an entry of type "METADATA", the coverage data is generated by emma when the java process was shutdown
3) I am using EMMA v2.1, build 5320 (stable)
4) when readUTF, the bytes in the data input stream were copied to a bytearr buffer, and once it's legal data of UTF, the byte data will be parsed to char, and put to buffer chararr.
I debugged and got the bytearr and chararr as below:
chararr:
, , o, r, a, c, l, e, /, c, e, p, /, u, t, i, l, /, X, M, L, H, e, l, p, e, r,
As you see, the utf string seems like a valid qualified class name, I mean this data is not corrupted or partial data due to process being killed abruptly.
I wonder why there were invalid -65 bytes in the UTF string, and how to avoid it.
by the way, why EMMA generates metadata(instrument data) at runtime, since I use offline mode
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I ran code coverage with emma, and finally I could not generate the report because of the following exception:
java.io.UTFDataFormatException: malformed input around byte 27
at java.io.DataInputStream.readUTF(DataInputStream.java:656)
at java.io.DataInputStream.readUTF(DataInputStream.java:564)
at com.vladium.emma.data.MetaData.readExternal(MetaData.java:235)
at com.vladium.emma.data.DataFactory.readEntry(DataFactory.java:734)
at com.vladium.emma.data.DataFactory.mergeload(DataFactory.java:426)
at com.vladium.emma.data.DataFactory.load(DataFactory.java:56)
at com.vladium.emma.report.ReportProcessor._run(ReportProcessor.java:176
Note that:
1) the file being processed is coverage data rather than a metadata file
2) the coverage data file contains an entry of type "METADATA", the coverage data is generated by emma when the java process was shutdown
3) I am using EMMA v2.1, build 5320 (stable)
4) when readUTF, the bytes in the data input stream were copied to a bytearr buffer, and once it's legal data of UTF, the byte data will be parsed to char, and put to buffer chararr.
I debugged and got the bytearr and chararr as below:
bytearr:
0, 25, 111, 114, 97, 99, 108, 101, 47, 99, 101, 112, 47, 117, 116, 105, 108, 47,
88, 77, 76, 72, 101, 108, 112, 101, 114, -65, -124, 107, -110, -49, -44, -92, -
chararr:
, , o, r, a, c, l, e, /, c, e, p, /, u, t, i, l, /, X, M, L, H, e, l, p, e, r,
As you see, the utf string seems like a valid qualified class name, I mean this data is not corrupted or partial data due to process being killed abruptly.
I wonder why there were invalid -65 bytes in the UTF string, and how to avoid it.
by the way, why EMMA generates metadata(instrument data) at runtime, since I use offline mode