The error isn't necessarily on this line: this is just where the exception
happens to be thrown when you try to push something on the execution stack and it is already full. You might even hit this line every time, but it isn't likely to be the cause. What is happening is pretty much either going to be infinite recursion. It is worth reviewing how this exception occurs, with a
simplified version of what is happening. Imagine the following code:
public void Foo()
{
MethodA();
Foo();
}
Now imagine the call stack has a maximum of 3 items (in reality, much larger than this - typically it will take a few seconds to fill).
- The first item is the original call to
Foo()
Stack Items = 1 - The first call to
MethodA()
pushes one to to the stack Stack Items = 2 MethodA
's implementation (not shown - it doesn't matter) always happens to push one item to the stack Stack Items = 3, this completes popping it back off Stack Items =2 As MethodA
completes, it is popped off the stack also Stack Items =1- Now the recursive call to
Foo()
is made, it is added to the stack, stack items = 2 - The second call to
MethodA()
pushes one to to the stack Stack Items = 3 MethodA
's implementation again tries to add one to the stack but the stack is full. The exception is thrown from this point in MethodA
So you've a situation that the error is thrown inside
MethodA
but the root cause is actually
Foo
calling itself without breaking out. Worse, the exception is effected by the size of the stack before the loop is executed and any difference to the stack (say due to conditional statements) inside the loop - you can get the exception potentially anywhere inside the loop. This makes this exception hard to trace sometimes.
The first thing you need to do is look at the exception stack trace. If you are lucky and you'll
see the loop happening, blocks of trace repeating over and over. In this case, you just need to find where in your code the break-out should happen and add code to break the loop. If you don't see your code anywhere then you are going to have to find the loop manually: to do this place breakpoints a different places you know are being executed when the exception happens (this can be in the initialisation code of a control don't forget) and see which are hit repeatedly. This should find your infinite loop hopefully.
Sorry this is such an essay!
[Edit - in repsonse to the OP's Comment]
Not sure whether I was clear about this, the stack cam fill anywhere in code executed inside the loop. the exception might be thrown in the designer code, but the loop will be happening around it. E.g. you have an infinitely recursive on a page, inside the loop a child control is created, the exception could happen in the child control that gets created (including any designer code that gets run, or anywhere else that happens to be excuted as part of the loop for that matter).
You need to look at the stack-trace when debugging. There will be stack trace on the exception (other than the displayed one on the YSOD, which is truncated IIRC there is a stack trace property that you can examine
http://msdn.microsoft.com/en-us/library/system.exception.stacktrace.aspx[
^])
Inside the stack trace is a list (OK stack :) ) of every method that was currently executing when the exception happened (Most recent at the top). In my example code you get the following order in the stack:
- ChildMethodOfA()<---Exception here
- MethodA()
- Foo() <--- Recursion here
- Foo()
Normally it isn't as clean as this, making getting to the bottom of the problem a bit of a dark art sometimes.You need to pick through the stack trace to spot where the loop happening, you'll see the same calls repeated inside the stacktrace, this should help you find useful breakpoints in your own code. With luck you'll be able to spot it quickly. If not, it becomes educated guesswork. You could put a breakpoint in the designer code and try and step through, eventually you'll see where the loop is happening in your code. If this doesn't work out, you need to decide make an attempt to find out what is executing the designer code when is throwing the exception. Again it it is a case of breakpoint --> step through until you see the recursion.
Note that you might [or even probably- this is easy to spot ] will find you have deeper recursion that isn't just MethodA calling itself, but is called by one or more intermediary methods.