crash due to large switch statement

in ilmorph.cpp at line 109 there is a buffer allocated to hold the current instruction.

20 bytes are allocated, this is not enough for some large switch statements.

I modified it to 2000 as below and my problems were fixed.

BYTE instrBuffer[2000];

Could you add this to master source code please.

Thanks,

Paul.

Re: No coverage report produced with MbUnit console

Hi mate,

I don't use MbUnit myself so I can't comment on that in particular if it's related to that. Hopefully it's just something else environmental.

What does the coverage.log file look like - feel free to email it to me.

What versions of the <ncover> task, NCover, MbUnit, .Net etc are you using?

Does NCover work for you from the command line, or have you tried running it from the NCoverExplorer 1.3.5 gui? I would suggest (if you havent already) eliminating the usual problems of coverlib.dll being registered etc.

Have you tried running it from the NCoverExplorer GUI/using the NAnt script it produces?

Have you tried it on a simple "HelloWorld" style test project?

Re: No coverage report produced with MbUnit console

hi there!

It's odd because when i use nunit, all is well, but when i use mbunit as the command to profile there are no reports generated even the coverage.log file.

Here are my environment specs:
NCover task: 1.3.5.1813
NCover: 1.3.3
MbUnit: 2.3 RC2
.NET: 1.1

NCover does not work both for command line and NCoverExplorer 1.3.5 GUI using MbUnit console as runner, issue of coverlib.dll not being registered i guess is eliminated since NUnit runner profiling works.

Re: No coverage report produced with MbUnit console

hey grant, i tried to install ncover version 1.5.4 and it was able to generate the reports. i guess 1.3.3 is problematic here.

Re: No coverage report produced with MbUnit console

Just a thought - your application isn't a .Net 2.0 app by any chance? Or have you referenced a .Net 2.0 version of MbUnit?

That might explain why profiling is only working with NCover 1.5.4 and not 1.3.3...

Re: Different test results in not mergable coverage results (v1.

Same problem here. I was afraid it was my fault though because NCoverExplorer was spitting out an error message indicating that the code came from different sources when it clearly did not.

Unfortuately I don't know how to fix or workaround the issue either.

Re: Different test results in not mergable coverage results (v1.

Only two people I am aware of now have raised issues with NCover 1.5.4. Perhaps most people are just running NUnit the once and hence no need to merge coverage files and thus not hitting the issue? Certainly that is what we do - add all the desired fixtures to a single NUnit project we create on the fly and run all tests in one go. You might consider this as a temporary workaround.

Just to add more publicly what I explained to Thomas when he reported this to me as an NCoverExplorer issue. I am constrained in my ability to merge coverage files due to there being no unique identifier for each method in the coverage xml files (unlike a GUID per method approach taken by VSTS code coverage). So instead I make the assumption that each coverage file has the same methods within it (just different visit count values which can be merged), and process by ordinal position. If I find a mismatch between the files then you will see the error being reported as a difference in the source code between coverage runs.

This is working fine for most but obviously some people are finding a situation where this is not the case.

In looking at the xml files Thomas sent me we find that while the same assemblies are being tested that for some reason NCover is inconsistently omitting methods that are not being hit by tests. They should be in the file with a visitcount of zero but for some strange reason they are excluded by NCover. We have discounted possibilities like conditional compilation under different tests etc - the same compiled binary assemblies are giving differing results with two different runs of unit tests.

There is little I can do from an NCoverExplorer perspective without massively changing the way I process xml files (sacrificing performance considerably), with the very real risk of breaking something that is working fine for most people currently. There are a number of corner cases I have to handle such as multiple AppDomains, overloads etc which make it not as trivial to get around as you might think.

I believe Thomas submitted a small repro case in another post on this forum somewhere - hopefully Peter can find some time soon to take a look and ensure that either consistent xml results are being produced or add a unique method ID I can use to merge with from NCoverExplorer.

Regards,
Grant.
http://ncoverexplorer.org/

Re: Different test results in not mergable coverage results (v1.

I have just made a change to the NCoverExplorer source code for the next release (1.3.4) to now hopefully handle this situation a lot better and allow the merge to take place. I have blogged about it at http://www.kiwidude.com/blog/2006/07/ncoverexplorer-merging-coverage-files.html

Regards,
Grant.
http://ncoverexplorer.org/