Bizarre crashes of the testing framework.

[GoogleCodeExporter]

This issue is related to this post - 
http://groups.google.com/group/mbunituser/browse_thread/thread/b010e995f210d6cf

The problem occurs now pretty often, which is extremely disturbing. I am 
attaching a zip archive with the results of running tests. We are pretty 
desperate, because of this issue.

Thanks.

Original issue reported on code.google.com by mark.kha...@gmail.com on 19 Oct 2010 at 7:06

Attachments:

• Debug.zip

[GoogleCodeExporter]

SOS
We are getting these messages pretty often:

Failures
An exception occurred while running test instance 'TestEntities'.
System.Runtime.Remoting.RemotingException: Port is Busy: All pipe instances are 
busy.

Server stack trace: 
   at System.Runtime.Remoting.Channels.Ipc.IpcPort.Connect(String portName, Boolean secure, TokenImpersonationLevel impersonationLevel, Int32 timeout)
   at System.Runtime.Remoting.Channels.Ipc.ConnectionCache.GetConnection(String portName, Boolean secure, TokenImpersonationLevel level, Int32 timeout)
   at System.Runtime.Remoting.Channels.Ipc.IpcClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
   at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Gallio.Runtime.ProgressMonitoring.RemoteProgressMonitor.Forwarder.SetStatus(String status)
   at Gallio.Runtime.ProgressMonitoring.RemoteProgressMonitor.SetStatus(String status) in c:\Server\Projects\MbUnit v3.2\Work\src\Gallio\Gallio\Runtime\ProgressMonitoring\RemoteProgressMonitor.cs:line 76

This is a relatively recent regression. Probably something we do in our tests, 
though I cannot think of any criminal acts there.

Original comment by mark.kha...@gmail.com on 20 Oct 2010 at 2:16

[GoogleCodeExporter]

Can you reliably reproduce it?

Original comment by grahamr...@gmail.com on 20 Oct 2010 at 2:37

[GoogleCodeExporter]

I can, however, it is not possible to isolate in a short example, because it 
happens when we run our integration tests, which means the (unit) test is the 
client of some server, which in turns talks to the database. As you can see, I 
cannot wrap it up and upload here.

However, I could collect diagnostics or run a debug build of gallio or whatever 
to let you have enough input to identify and solve the problem.

Original comment by mark.kha...@gmail.com on 20 Oct 2010 at 4:24

[GoogleCodeExporter]

Run it as IsolatedAppDomain, if there are no problems then it is due to 
remoting. In which case you need to identify which test or tests is causing the 
problem.

Original comment by grahamr...@gmail.com on 22 Oct 2010 at 8:35

[GoogleCodeExporter]

Sounds like it's interfering with Gallio's own remoting.  We should really drop 
our use of .Net remoting and send directly messages over a domain socket or a 
named pipe instead.

Original comment by jeff.br...@gmail.com on 28 Nov 2010 at 11:35

[GoogleCodeExporter]

We are having the same problem here - same exception. This, and some extremely 
frustrating memory problems where running certain fixtures suddenly ups 
Gallio.Host.exe memory usage to 2+GB (after 10 or 15 or so tests), then back to 
the normal 50:ish MB, then back up to 2+GB, and so on. No idea if those are 
related, but it all started happening roughly 3+ weeks ago. If I run only the 
test(s) where memory goes down the drain, it's all fine. If I run around 10 
tests at the time instead of the whole fixture, it's also fine.

We have not changed the Gallio version (3.1 Build 397), and all those tests 
have been run over and over again for a long time, only to start failing now. 
We are not using Remoting in our tests.

Occurs on both Windows 7 and Windows Server 2008 R2. It doesn't seem completely 
unlikely that it's related to some Windows Update, but we haven't been able to 
figure it out.

Original comment by mikael.r...@gmail.com on 6 Feb 2011 at 11:11

[GoogleCodeExporter]

Short update. I have been suspicious of the HTML output generation vs. having 
large test suites, so we tried running Echo with text as output instead. This 
time, we did manage to run it all without Remoting Exception and without memory 
issues.

Instead, we got "System.CannotUnloadAppDomainException: Error while unloading 
appdomain". However, we have seen this before and it's likely/hopefully 
unrelated.

We'll continue to dig, but I am still puzzled why it suddenly became a problem.

Original comment by mikael.r...@gmail.com on 7 Feb 2011 at 9:06

[GoogleCodeExporter]

Thank you for the follow-up.

We've replaced the XSL-based engine to generate HTML reports by a faster engine 
based on Castle NVelocity. But it's still only in the v3.3 trunk. And it's not 
enabled by default yet. We will also provide a functionality to split large 
HTML reports into several smaller child files.

It should be usable in the v3.3 trunk in a couple of weeks. And I expect it to 
be available in v3.2.x release (maybe 4, after the next feature release) in the 
current of year (summer?)

Original comment by Yann.Tre...@gmail.com on 7 Feb 2011 at 9:18

• Added labels: Component-Gallio, Milestone-3.2.4, Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

Could you get us a dump when the memory usage is very high?

Original comment by grahamr...@gmail.com on 7 Feb 2011 at 10:52

[GoogleCodeExporter]

Original comment by Yann.Tre...@gmail.com on 14 Jun 2011 at 5:48

• Added labels: Milestone-3.3

[GoogleCodeExporter]

Original comment by Yann.Tre...@gmail.com on 14 Jun 2011 at 5:53

• Added labels: Milestone-IdeaPool

[GoogleCodeExporter]

did you guys find any solution ,I am also facing same issue

Original comment by anurag....@gmail.com on 7 Aug 2013 at 5:09