views:

343

answers:

6

Say you have a method that could potentially get stuck in an endless method-call loop and crash with a StackOverflowException. For example my naive RecursiveSelect method mentioned in this question.

Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default. Consequently, users are advised to write their code to detect and prevent a stack overflow. For example, if your application depends on recursion, use a counter or a state condition to terminate the recursive loop.

Taking that information (from this answer) into account, since the exception can't be caught, is it even possible to write a test for something like this? Or would a test for this, if that failed, actually break the whole test-suite?

Note: I know I could just try it out and see what happens, but I am more interested in general information about it. Like, would different test frameworks and test runners handle this differently? Should I avoid a test like this even though it might be possible?

+2  A: 

How about checking the number of frames on the stack in an assert statement?

const int MaxFrameCount = 100000;
Debug.Assert(new StackTrace().FrameCount < MaxFrameCount);

In your example from the related question this would be (The costly assert statement would be removed in the release build):

public static IEnumerable<T> SelectRecursive<T>(this IEnumerable<T> subjects, Func<T, IEnumerable<T>> selector)
{
    const int MaxFrameCount = 100000;
    Debug.Assert(new StackTrace().FrameCount < MaxFrameCount);

    // Stop if subjects are null or empty
    if(subjects == null || !subjects.Any())
        yield break;

    // For each subject
    foreach(var subject in subjects)
    {
        // Yield it
        yield return subject;

        // Then yield all its decendants
        foreach (var decendant in SelectRecursive(selector(subject), selector))
            yield return decendant;
    }
}

It's not a general test though, as you need to expect it to happen, plus you can only check the frame count and not the actual size of the stack. It is also not possible to check whether another call will exceed stack space, all that you can do is roughly estimate how many calls in total will fit on your stack.

0xA3
Hm... when and where would you do this? Not sure if I'm following...
Svish
This should happen inside your recursive function. It's not a general test though, as you need to expect it to happen, plus you can only check the frame count and not the actual size of the stack.
0xA3
Exactly. Interesting solution, but not I don't think I would like to have something like that in my methods, hehe.
Svish
Probably more of a pragmatic than a beautiful approach, but don't forget that the costly `Debug.Assert` statement is removed in the release build.
0xA3
Yeah, thats true.
Svish
+1  A: 

We cannot have a test for StackOverflow because this is the situation when there is no more stack left for allocation, the application would exit automatically in this situation.

Ravia
Exactly. So any test-runner would pretty much crash completely if such a test failed? Or?
Svish
why did you down vote...?
Ravia
Ravia, you are missing the point. It's true that you can't test for stack overflow, but that is not what you should test for. You keep track of how deeply your method is nested, to protect yourself from an eternal loop.
Guffa
+4  A: 

You would need to solve the Halting Problem! That would get you rich and famous :)

Mongus Pong
Awesome... will start working on that then! Right... :p Silliness aside, I guess the answer for this question would be something along the lines of "No can do" then. Oh well :)
Svish
@ Svish - you can do it, it's just not terribly natural. It requires running the code under test in another process and dealing with the pain that is checking the result of that process.
Mike Two
I refer you to the work of Dr Byron Cook who has sucessfully developed techniques to prove that certain kinds of code will terminate. http://www.bcs.org/server.php?show=nav.11472
Tom Duckering
(not recursive code however :op )
Tom Duckering
The halting problem doesn't really have anything to do with this question. A method that is proven to exit can easily cause a stack overflow, and the fact that a method never exits doesn't cause a stack overflow by itself.
Guffa
@Guffa: Good point, but it does have something to do with it, doesn't it? Certainly made sense to me anyways... hehe.
Svish
@Guffa, true. The halting problem is more a logical problem which applies to machines with infinite resources, whereas stack overflow occurs on machines with limited resources. Still it highlights the difficulties that you would get trying to predict a stack overflow.
Mongus Pong
A: 

It's evil but you can spin it up in a new process. Launch the process from the unit test and wait for it to complete and check the result.

Mike Two
A: 

The idea is to keep track of how deeply a recursive funcion is nested, so that it doesn't use too much stack space. Example:

string ProcessString(string s, int index) {
   if (index > 1000) return "Too deeply nested";
   s = s.Substring(0, index) + s.Substring(index, 1).ToUpper() + s.Substring(index + 1);
   return ProcessString(s, index + 1);
}

This of course can't totally protect you from stack overflows, as the method can be called with too little stack space left to start with, but it makes sure that the method doesn't singelhandedly cause a stack overflow.

Guffa
A: 

First and foremost I think the method should handle this and make sure it does not recurse too deep.

When this check is done, I think the check should be tested - if anything - by exposing the maximum depth reached and assert it is never larger than the check allows.

asgerhallas
Of course it should handle it. But in the spirit of not thrusting untested code, how would you know for sure that it in fact was handling it properly without a test for it?
Svish
That's why I think you should test the "handling of it". Of course you cannot test when the handling fails, but you can test that it does not actually overflow the stack when you feed it with data, that otherwise (without the handling) would. But when I re-read your question I can see, that's is not what you're asking. Sorry :)
asgerhallas