thank you for submitting. Your bug report helps us to improve csUnit.
Our assumption is that for all practical reasons a user wants to have immediate, fast, and direct feedback about the progress of tests. Running tests in the host process is significantly faster than creating a separate process and running tests in that separate process. As a consequence we have designed csUnit4VS (the addin) so that it executes tests in the same process but in a separate appdomain.
(I wonder how ASP.NET hosting providers deal with it. Any idea?)
So in essence by default StackOverflowException cannot be caught and will take down the entire process.
The other options we have:
- Run tests in a separate process. Then only that other process would be taken down.
- Host the CLR yourself in which case you could set a different policy for what to do when the stack overflows.
If follows that recursion should be avoided where possible.
As for csUnit: We will re-assess the effort for running tests in a separate process (has a number of consequences!) and consider it for a future version.
Further to my initial comment we may - at some point - experiment with the plug-in mechanism that is available in .NET 3.5 and later. That may address certain issue but may not resolve the problem if you unmanaged code is invoked indirectly.
Logged In: YES
user_id=280452
Originator: NO
Hi Chris,
thank you for submitting. Your bug report helps us to improve csUnit.
Our assumption is that for all practical reasons a user wants to have immediate, fast, and direct feedback about the progress of tests. Running tests in the host process is significantly faster than creating a separate process and running tests in that separate process. As a consequence we have designed csUnit4VS (the addin) so that it executes tests in the same process but in a separate appdomain.
Unfortunately, starting with .NET 2.0 it is no longer possible to catch StackOverflowExceptions. The runtime prevents it. The process terminates by default. See the following link (copy into a single line if necessary):
http://msdn.microsoft.com/en-us/library/system.stackoverflowexception.aspx
Here is a link to yet another discussion on the subject:
http://www.themssforum.com/Framework/StackOverflowException-139254/
The same applies by the way for ASP.NET applications. Stack overflow crashes their host process as well. For instance use the following blog post as a starting point (copy into a single line if necessary):
http://blogs.msdn.com/tess/archive/2008/05/06/asp-net-crash-stackoverflowexception-with-server-transfer.aspx
(I wonder how ASP.NET hosting providers deal with it. Any idea?)
So in essence by default StackOverflowException cannot be caught and will take down the entire process.
The other options we have:
- Run tests in a separate process. Then only that other process would be taken down.
- Host the CLR yourself in which case you could set a different policy for what to do when the stack overflows.
If follows that recursion should be avoided where possible.
As for csUnit: We will re-assess the effort for running tests in a separate process (has a number of consequences!) and consider it for a future version.
I'll reclassify this item as a feature request.
Kind regards,
Manfred.
---
Manfred Lange
csUnit developer
http://www.csunit.org
http://manfredlange.blogspot.com (on .NET)
http://agileleadership.blogspot.com (on Agile Management)
Hi Chris,
Further to my initial comment we may - at some point - experiment with the plug-in mechanism that is available in .NET 3.5 and later. That may address certain issue but may not resolve the problem if you unmanaged code is invoked indirectly.
Kind regards,
Manfred.
---
Manfred Lange.
csUnit developer
http://www.csunit.org