Menu
▾
▴
#275 coverage issue and crashing
The attached example can be used to crash covered and for some cases appears to be not showing full coverage. Doing some tricks I can get 100% coverage for one case, but not for the other. I think the tricks are not need and it should be 100% for the base test. This is fairly well documented in the source, but there are two types of statements and two limit values. There's also the crash issue after it warns about a possible race that goes away when <= is used instead of =. Let me know if you need more information. Yes this code is a bit strange!
example files
Attaching a patch to fix the crash issue.
Bug fix patch for crash issue
Cary,
I have the bug fixed for the crash issue, but I'm not seeing what the coverage issue is. Which coverage points are not being reported as hit that you expect to have it?
Thanks,
Trevor
Trevor,
I would have expected the ternary and if built code to have the same coverage given the same input. I'm also uncertain why changing the code from 15 to 16 makes a difference in coverage. I would have expected a count up and down would have been enough. The roll that going to 16 creates is basically an extra down and then up count. It was a very long day so it's entirely possible I missed something in my analysis.
I'm seeing many failures when using the if code and a count of 15, only one failure for the ternary code. With a count of 16 the ternary is 100%, but the if code still has one case that does not get covered. The if code with a count of 15 was showing line coverage issues which I know could not exist. This is all from memory. I was expecting 100% coverage for both the if and ternary code using a count of 15. I was not expecting them to have different coverage results and I was not expecting that changing the code to 16 would make things better.
Cary
Cary,
I'm seeing the same coverage issues on my end. This problem is due to the way that I am treating the inputs to the example module. Covered gets the module input information from the dumpfile which it treats as an assignment made by a non-blocking assignment (however, val is assigned by a blocking assignment). This is what leads to the coverage issues. The fix for this is non-trivial since dumpfiles cannot tell me whether a signal was dumped to the dumpfile via a blocking or a non-blocking assignment :< This is a problem with a non-trivial solution, in my opinion. But it most definitely is a problem that needs to be solved.
Changing the value from 15 to 16 causes the value of "val" to hold a value of 0 while res decrements. This holding of the value helps Covered evaluate the example module always block correctly, leading to better coverage results (it basically masks the issue that I explained above).
The solution to this issue is going to take some time from me to think through. I'll provide an update when I have a solution for you to try.
Thanks,
Trevor