When emma instruments my classes, I get the following message:
line coverage requested in a report of type [html] but
not all instrumented classes were compiled with line number
debug data: this column will be removed from the report.
I am using emma from within ant, and the files have been compiled with a javac task with the debug=on option. I know this has line numbering information because when I get exceptions, it includes file/line number information, yet emma complains that this information is missing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You must have some classes that are not compiled with debug on. Occasionally, such classes could be produced by rmic and need to be filtered out.
Unless you have disabled EMMA logging, both <instr> and <report> should log examples of classes that lack full debug info: you can use that to debug your build.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am aware of which classes that Emma is reporting as not having full debug info. My question is how do I enable full debugging for these classes? I have explicitly compiled them using Ant's 'javac' task, with the 'debug' option set to 'true', which to my understanding should do the trick. Indeed, when I compile classes in this way and get an Exception, the stack trace does indeed show the line number where problems occur, which tells me that the classes *do* have debugging info. I am wondering if somehow the problem is the fact that I am using a 'junit' task to execute my compiled classes might be an issue? I am using 'fork' set to 'true', as emma requires, but I'm wondering if there might be some other problem here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(a) the classes in question are indeed compiled with full debug info and EMMA has a bug whereby it mistakenly thinks this is not the case:
create a new bug issue in Tracker and attach some of those .class files.
(b) perhaps you have compiled these classes once without debug info and that metadata is somehow still around:
remove all EMMA output files (*.ec, *.em), do a clean build and see if the problem remains.
If you want to enable more EMMA logging, you can set "verbosity" attribute on its ANT tasks to "verbose", "trace1", "trace2", "trace3". The last 3 levels probably won't be useful to you (and they can generate a lot of info).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found the source of the problem. The classes that are giving me this problem are ones that have been "enhanced" by my JDO byte-code enhancer. I am using the JPOX implementation of JDO. I am not sure if they're modifying the byte-codes improperly or if they're just changing them in such a way so that Emma is not able to recognize that the debug info is still there. How is Emma checking for the debug info?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I've solved my problem, however I think that there might still be a problem with EMMA. EMMA does not seem to play well with byte-code that has already been enhanced by something else. In my case, JDO also does byte-code enhancement, and after this, EMMA seems to think that the code is not fully debug-enabled, when in fact it is. When I change it so that EMMA does the byte-code enhancement first, followed by JDO, then everything works fine. I even get proper indications of where my code has and has not been covered.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am glad you sorted this out. However, I would change your statement of "EMMA does not seem to play well with byte-code that has already been enhanced by something else" to pretty much the opposite: it is the other tools that don't know how to play nice.
EMMA detects presence of full debug info by checking for SourceFile and LineNumberTable .class attributes. These are two standard attributes for a .class format and they are emitted, for example, by javac when you do -g.
Not only does EMMA continue to emit these two attributes for its instrumented classes so its instrumentation is as transparent as possible, it goes to some extra trouble and adjusts all bytecode offsets in LineNumberTable so that your exception stack traces are correct. (See my recent post in ADVANCED-JAVA on how the info displayed in a stack trace is determined by those two .class attributes: http://discuss.develop.com/archives/wa.exe?A2=ind0408&L=advanced-java&T=0&F=&S=&P=1567\)
Just like you argued that your classes had full debug info because it showed up in the stack traces you can verify for yourself that it correctly remains there if an exception is thrown from an EMMA-enhanced class.
Unfortunately, I believe the majority of other bytecode enhancers out there assume they are the only tool in the chain. My guess would be that they simply drop these (optional) debug attributes to save the effort of keeping them consistent. Hence to make the overall chain work you have to keep the least friendly tool last in the chain. This seems to have been your case precisely.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the details of how Emma enhances the byte-code while remaining transparent. I was able to solve my problem by having Emma enhance the code first, and then have the other tool enhance it afterwards. As it turns out, this is a better alternative anyhow, since otherwise the methods added to the class by the other tool would end up getting instrumented and included in the code coverage analysis, which is not what is desired.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When emma instruments my classes, I get the following message:
line coverage requested in a report of type [html] but
not all instrumented classes were compiled with line number
debug data: this column will be removed from the report.
I am using emma from within ant, and the files have been compiled with a javac task with the debug=on option. I know this has line numbering information because when I get exceptions, it includes file/line number information, yet emma complains that this information is missing.
You must have some classes that are not compiled with debug on. Occasionally, such classes could be produced by rmic and need to be filtered out.
Unless you have disabled EMMA logging, both <instr> and <report> should log examples of classes that lack full debug info: you can use that to debug your build.
I am aware of which classes that Emma is reporting as not having full debug info. My question is how do I enable full debugging for these classes? I have explicitly compiled them using Ant's 'javac' task, with the 'debug' option set to 'true', which to my understanding should do the trick. Indeed, when I compile classes in this way and get an Exception, the stack trace does indeed show the line number where problems occur, which tells me that the classes *do* have debugging info. I am wondering if somehow the problem is the fact that I am using a 'junit' task to execute my compiled classes might be an issue? I am using 'fork' set to 'true', as emma requires, but I'm wondering if there might be some other problem here.
The only choices I can think of are:
(a) the classes in question are indeed compiled with full debug info and EMMA has a bug whereby it mistakenly thinks this is not the case:
create a new bug issue in Tracker and attach some of those .class files.
(b) perhaps you have compiled these classes once without debug info and that metadata is somehow still around:
remove all EMMA output files (*.ec, *.em), do a clean build and see if the problem remains.
If you want to enable more EMMA logging, you can set "verbosity" attribute on its ANT tasks to "verbose", "trace1", "trace2", "trace3". The last 3 levels probably won't be useful to you (and they can generate a lot of info).
I found the source of the problem. The classes that are giving me this problem are ones that have been "enhanced" by my JDO byte-code enhancer. I am using the JPOX implementation of JDO. I am not sure if they're modifying the byte-codes improperly or if they're just changing them in such a way so that Emma is not able to recognize that the debug info is still there. How is Emma checking for the debug info?
OK, I've solved my problem, however I think that there might still be a problem with EMMA. EMMA does not seem to play well with byte-code that has already been enhanced by something else. In my case, JDO also does byte-code enhancement, and after this, EMMA seems to think that the code is not fully debug-enabled, when in fact it is. When I change it so that EMMA does the byte-code enhancement first, followed by JDO, then everything works fine. I even get proper indications of where my code has and has not been covered.
I am glad you sorted this out. However, I would change your statement of "EMMA does not seem to play well with byte-code that has already been enhanced by something else" to pretty much the opposite: it is the other tools that don't know how to play nice.
EMMA detects presence of full debug info by checking for SourceFile and LineNumberTable .class attributes. These are two standard attributes for a .class format and they are emitted, for example, by javac when you do -g.
Not only does EMMA continue to emit these two attributes for its instrumented classes so its instrumentation is as transparent as possible, it goes to some extra trouble and adjusts all bytecode offsets in LineNumberTable so that your exception stack traces are correct. (See my recent post in ADVANCED-JAVA on how the info displayed in a stack trace is determined by those two .class attributes: http://discuss.develop.com/archives/wa.exe?A2=ind0408&L=advanced-java&T=0&F=&S=&P=1567\)
Just like you argued that your classes had full debug info because it showed up in the stack traces you can verify for yourself that it correctly remains there if an exception is thrown from an EMMA-enhanced class.
Unfortunately, I believe the majority of other bytecode enhancers out there assume they are the only tool in the chain. My guess would be that they simply drop these (optional) debug attributes to save the effort of keeping them consistent. Hence to make the overall chain work you have to keep the least friendly tool last in the chain. This seems to have been your case precisely.
Thank you for the details of how Emma enhances the byte-code while remaining transparent. I was able to solve my problem by having Emma enhance the code first, and then have the other tool enhance it afterwards. As it turns out, this is a better alternative anyhow, since otherwise the methods added to the class by the other tool would end up getting instrumented and included in the code coverage analysis, which is not what is desired.