Question

In Visual Studio 2012, I am starting the application using debugging. I open some screen, then close it. At this point, when I look at Call Stack, I can see the starting point in my app, some methods that opened / closed the screen, and lots of (external) calls not from my app. What I notice is that many of the calls in my application are not listed, although they have been executed.

I placed a breakpoint in my app. When application hits the breakpoint, I start stepping into the code using F11. Basically what it does is, it calls SomeMethod from a loop (breakpoint is set in a loop).

When I use F11 to enter to SomeMethod, I see that SomeMethod is listed in call stack, but if I hit F5, and then hit again a break point (in a loop), and look at call stack again, SomeMethod is not listed any more.

So, how does a Call Stack decide what methods to show in it? And how can we get the full list of methods that have been executed?

Was it helpful?

Solution

The call stack is not a list of methods which have been called, it is a list of methods which have been called but not returned to.

Let me explain

I'll give a simple example first of one function call. While running a program makes a call to the function. To do so it pushes the parameters and the location of itself onto the stack. (This is now at the top of the stack). It then calls the function which jumps the instruction pointer to where there code for that function is located. That function pulls it's parameters off the stack (it was just called so it knows they must be on the top of the stack) and runs it's local code. When it is done it pulls the return address off of the stack and uses it to return the instruction pointer to where this function was called from.

Now in the more complex case, any function can call any other function -- it will work exactly the same but now the stack will contain the first function called on the bottom of the most recently called function. Because you always take from the top of a stack you will always be returning to the location from where the last call was made.

OK, so when looking at the call stack in the debugger you will see all the function calls made prior to the location you are at in the program. At some point the code will return to those locations listed in the stack. However, if a function call was already returned from it will no longer be on the stack, it has been popped from the stack when that function returned.

OTHER TIPS

The call stack only shows methods that are currently "in progress" (they haven't exited yet) for a particular thread. The stack does not include methods that have been completed.

The easiest way to figure out what methods ran (or didn't) is to use a profiler. In Visual Studio, it's called "Performance Analysis" (found under the Analyze menu).

If you're new to profiling, I would suggest using the "Performance Wizard" (also on the Analyze menu). Select "Instrumentation" as the profiling method, as that will give you the function call counts (sampling may miss method calls that didn't take much time).

It also bears mentioning that the profiler will not give an ordering of method calls. It will only count them. If you need to know the ordering of method calls, you'll need to track this manually (by adding code to the beginning and/or end of each method to log the call).

Call stack does not show methods that have been executed previously. Instead they show the method call tree/stack/hierarchy that are executing right now. The first method is the one that you are currently in - usually where you set the breakpoint or step into using debugger.

You can see this by using 'Step out' command - this will jump you right to the next method in the call stack.

A call stack is a stack data structure that stores information about the active subroutines. When the method has finished, it is no longer considered as active and therefore will not be displayed on the call stack. Basically, the call stack that you can see is the current path of method calls to get to the point where the break point was hit.

I think you have a misconception on what the call-stack actually is. Whenever a method calls into another method, the address of where it was in the old method is pushed onto the stack. Once it returns back to that method it is popped off the stack and will no longer be seen.

It is not a recording of all methods that have been called, but a list of where execution will return to when the current block of execution has completed.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top