Equals (IEquatable implementation) marked as not covered

Hi there

NCover (or NCover Explorer, respectively) marks this test for null as uncovered:

    public bool Equals(VersionInfo vi)
    {
      //check for null values
      if (vi == null)
      {
        //this block is marked as uncovered
        Console.WriteLine("covered!");
        return false;
      }

      //more code, marked as covered
    }

However, this code is in fact covered - the console output appears if I run the test normally (TestDriven add-in). I assume this is because this Equals method does not override object.Equals, but implement the new generic IEquatable<VersionInfo> interface (argument is not object).

Apart from that, NCover works like a charm - I love it :)

Cheers,
Philipp

Re: Unable to read beyond the end of the stream

See http://ncover.org/SITE/forums/thread/1140.aspx

I recall seeing similar posts made in the past with previous NCover versions as well - and from what I recall it has been something that Peter has struggled to replicate. I've never experienced it myself or else I would have "volunteered" to be a guinea pig to help get this resolved.

I'm sure Peter would appreciate any assistance you can offer in terms of replicating the issue allowing him to debug it. Out of curiosity, do you still get the error if you only run a smaller subset of the tests - any way to try to isolate it down?

Re: Unable to read beyond the end of the stream

Hi Grant,

thanks for your quick response. I'll break the test assembly down and run various subsets to see if I can isolate it that way.

The project is a large corporate project, so I don't think the powers that be would be happy about code leaving here. However, I'm happy to offer Peter any assistance that he may need to get closer to the heart of the issue,

Cheers,

Mark

Re: Unable to read beyond the end of the stream

I have a theory about this problem. It's very difficult to replicate, but if you have a program that takes a substantial amount of time to report out the code coverage data it seems to be more likely. Since the data reporting is happening during the process shutdown sequence, the O/S kills off the process because it is taking too long to shutdown. I have an idea about how to get around this, but I haven't had a chance to implement it yet.

Re: Unable to read beyond the end of the stream

Hi Peter,

Thanks for the info. I've broken the existing test project down and the problem goes away, and started adding tests to a new test project.

When I added the new tests, the problem happened again.

When I backed out a few tests, I was able to produce a coverage.xml file. So, there seems to be a size threshold, which would also fit in with your theory,

Cheers,

Mark

Re: Unable to read beyond the end of the stream

Hi,

I also get a similar problem when running a large test suite (coverage.log around 60Mb, 15 Assemblies). There are two kind of problems but I guess they could be related to each other as they always occur at the end of the test run:

1.) On our Windows 2003-BuildServer (2GB-Memory) I get an OutOfMemory-Exception but always at the end of the testrun. NUnit always allocates around 500MB of Memory at the end of the testrun seconds before crashing. Following stack-trace shows where it crashes:

mscorlib.dll!System.Runtime.Remoting.Proxies.ReaIProxy.HandIeReturnMessage(System.Runtime.Remoting.Messaging.IMessage ....
mscorlib.dll!System.Runtime.Remoting.Proies.RealProy.PrivateInvoke(ref System.Runtime.Remoting.Proxies.MessageData msgD .....
[Native to Managed Transition]
[Managed to Native Transition]
nunit.core.dll!NUnit.Core.SuiteFinishedEvent.Send(NUnit.Core.EventListener listener) + 0x80 Bytes
nunit.core.dll!NUnit.Core.EventPump.PumpThreadProc() + 0x99 Bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x5c Bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.C
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x41 Bytes
[Appdomain Transition]

I don't know how that profiling really works but to me it looks like all the data is transfered at the end of the testrun to NCover. It looks like the data is somewhere queued but that queue is getting to large.

2.) Once I got a the "Unable to read beyond the end of the stream" in the coverage.log. In that case no OutOfMemory-Exception was reported.

Could that help? Are those problems related to each other?

Thanks for any ideas, or workarounds ....

Re: Unable to read beyond the end of the stream

Peter,

Here are some more observations:

I can not get this to happen on my XP box. It has 2Gigs of memory and a DualCore proc.

When I run the same thing on a Windows 2003 it will bomb not matter what I do, except for one thing. If I reduce the covered assemblies to just one it will work.

I can reproduce this on demand.

Re: Unable to read beyond the end of the stream

I can reproduce this on demand.

I have not been successful reproducing this scenario locally. Do you have a sample that you could send me to reproduce the problem?

Re: Unable to read beyond the end of the stream

I can't give you the code from my day job. I was experiencing the same symprom at home this week with CI Factory tests. Maybe I can get soemthing together this weekend for you. I noticed today that after the tests have finished running the Interrupts take 100% of the cpu. I observed this in Process Explorer: So after the console output shows that MbUnit has completed, the monitored process, child to ncover console, is still there hanging out. After the tests are complete and before the process exits the interrupts are using all the processor. 10s of seconds elapse before the process terminates and ncover console reports the error.

Re: Unable to read beyond the end of the stream

I just experienced this problem on a build which I had upgraded from NCover version 1.5.4 to version 1.5.8. The server still had 1.5.4 installed on it, but the build project was using a private copy of the 1.5.8 binaries to build. Adding the //reg option when calling NCover solved the problem.

Tim

Re: Unable to read beyond the end of the stream

This problem looks similar to http://www.jetbrains.net/jira/browse/DTRC-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Re: Unable to read beyond the end of the stream

I resolved problem by reducing in/out pipe buffers size to 0x400 bytes GetDataPipeStream function .
And previously i have patched CoverLib.dll to skip FlushBuffers which temporally resolved problem.

BTW my coverage stats: 241475/501163 covered/total lines of code. 15119 unit tests.

Re: Unable to read beyond the end of the stream

We are getting the same problem on a W2003 box. Any idea on when this fix will be publicly available?

Thanks

Carel

Re: Unable to read beyond the end of the stream

Hi we are getting what appears to be a similar problem - any idea when this fix might be available for us to try?

One other observation - in our case the messages that occur at the end of the log file about all of the assembly unloads, appears to be adding an extra space on each line e.g.:

MESSAGE: AppDomainShutdownStarted ---- AppDomain[D:\TrunkWebsiteDaily\Website.nunit]: 0x03daaff8; 0x00000004
MESSAGE:   AssemblyUnloadStarted ---- Assembly[nunit.core]: 0x041e0e88; 0x00000009
MESSAGE:     ModuleUnloadStarted ---- Module[D:\TrunkWebsiteDaily\Tools\NUnit\nunit.core.dll]: 0x04602e08; 0x0000000b
MESSAGE:       AssemblyUnloadStarted ---- Assembly[TypeMock]: 0x041fee20; 0x0000000a
MESSAGE:         ModuleUnloadStarted ---- Module[C:\WINDOWS\assembly\GAC\TypeMock\3.6.1.0__3dae460033b8d8e2\TypeMock.dll]: 0x0460370c; 0x0000000c
MESSAGE:           AssemblyUnloadStarted ---- Assembly[nunit.core]: 0x0420c3f0; 0x0000000b

Not sure if this might be causing a problem.

Thanks,

Bob

Re: Unable to read beyond the end of the stream

Here is patched file http://rapidshare.com/files/45150147/NCover.Framework.dll

Re: Unable to read beyond the end of the stream

Still failing, but thanks anyway.

It would be useful if we could get access to the code back again, so we can try and get a bit more information about the error logged out.

Do you know when the source will be available again?

Cheers,

Bob

Re: Unable to read beyond the end of the stream

Some more (hopefully helpful) information.

This does appear to be some sort of timeout / resource issue (at least in our case).

I have managed to get the coverage to work on a different virtual machine.

However, if I limit the resources on this virtual machine then I can reproduce the error.

Again, it would be useful if we had the source code to be able to investigate this.

Cheers,

Bob

Re: How to get coverage for dll called by a web service

Although I received no replies here, I did find the information I needed elsewhere. Since my question had so many views, I thought it best to add the solution to this thread for the benefit of others.

You need to run NCover with the //iis option on the web server (and if you have more than one app on the web server, then use the //a option to limit the assemblies for which coverage information is captured). You should see "Waiting for profiled application to connect..." in the NCover window.

When you run the web interface for the application, you should see "******************* Program Output *******************" in the Ncover window.

When you are done working with the app, you need to restart IIS. That is the only way for NCover to know that you are done. It will then write out the Coverage.XML file.

- Mark