Stopping a running test on an agent


I'm hoping to find some awnser to a problem that's frequently occuring on our build agents.

We have a TeamCity 6 environment with around 13 agents running. We rely on TeamCity to run our UnitTest against various databases such as Oracle, MSSql and Sqlite.
We also use these build agents to run WaTiN tests for integration tests, usability tests and checking the correctness of the website.

The problem we are encountering, is that sometimes on random agents we have like 20 instances of a browser running. And alot more threads running idle on the system. This causes subsequent tests to fail because the maximum number of browser instances is exceeded on the machine. We have adjusted the code of our WaTiN tests to use the IDisposable pattern and clean up the mess once a test is done.
However, we are noticing that if we cancel a running test, the following tests on that machine start to create unescecarry browser instances and other instances keep lingering.

To further investigate, we're trying to find out how teamcity actually stops a running test? Does it raise a ThreadAbortedException inside the running thread, or does it just dispose of the Thread?
We currently believe the latter to be true, as it would explain why the finally block of our code is not working/getting called and we end up with rogue threads and browsers.

Anyone who has encountered this, or can shed some light on this?

Comment actions Permalink

1 week since I posted this, and nobody has anything to say or encountered this ?

Comment actions Permalink

Hello Arne,

  Sorry for the lag with communication.

  When TeamCity cancels the running build, it kills the underlying build process and all its subprocesses.
  I.e. it destroys the process tree starting from the first process started by the build.

  I'm not why there are lingering processes left by the build after this, may be they somehow detached from the process tree during the build.


Comment actions Permalink

cheers for the reply.
I'm currently investigating the issue closer with the person who created the WaTiN Framework, and if TeamCity indeed kills the process and subprocess abrubtly, it's important info that can help our search.


Please sign in to leave a comment.