How to get sequential trace of functions calls and events?

Abdu

I am interested in knowing the order of function calls and events. The performance profiler lists only the functions a long time and the memory profiler doesn't give what I need. It gives a long list of strings. I would like to see the life cycle of a web page.

abdu

Brian Donahue

Thanks abdu, we're looking into it.

There is a hierarchy panel in the bottom half of the profiler results that will show which method(s) had called the particular method you're looking at. This goes some way to tracing. But it is probably not exactly what you're asking for. Memory results include the referenced from and refers to chain and also a stack trace that shows the chain of events that caused the object to be created. Hopefully this helps a bit.

Rim Shot

I am looking for the same thing... except at a more detailed level.

Every now and then, it would be very helpful to get an execution trace instead of having to single step through a million lines of code.
Instrumenting the code manually is too laborious and too invasive. I may not have the source code anyway.

An internet search turned up one product that almost does what I want.

http://www.sparxsystems.com/resources/demos/debuggingcs/debuggingcs.swf

The last 30 seconds show an execution trace diagram.
I have not used their product, but it looks like it works at the method level only.

The ability to drill down to individual lines is ABSOLUTELY CRITICAL, since the reason I need the tool is to find unexpected side-effects.

For example: Setting a value in a DataRow object can result in a new DataRow being created--producing mystifying results. You can see it happen if you configure the debugger not to skip generated code and then single step very carefully, but you're going to take a long time finding it.

An comprehensive execution trace could identify these side-effect type problems much more easily.

Brian Donahue

Hi,

I should have read your post more carefully, so I could skip to the last 30 seconds of the flash demo to see the call graph because the steps to set up a project in sparx are really, really long! :-)

I'd like to point out that ANTS Profiler really doesn't require that you have source code as instrumentation can pick up method names and call stacks without that. The only limitation is you wouldn't have a source code view, unsurprisingly. The implication is that ANTS can give you at least some indication as to the performance of Microsoft's FCL and any third-party assemblies if you want it. Or filter them out if you don't.

It's interesting to see the blurry line between debuggers and code profilers. Debuggers, and by association sampling code profilers, have less of a performance impact. But if you want accuracy, instrumenting your code is going to trump sampling as it's based on periodic snapshots of the runtime environment instead of a continuous, event-driven process running in your own program.

ANTS Profiler is not concerned with the type of project being profiled, only the IL. So you cannot specifically gather information about a 'web page', but you can look only at the class or namespace the page is in if you want. Quite a lot of the functionality of ASP .NET is dependent on IIS. For example, you may be memory profiling and wondering why some objects are staying alive, and finding out that the reason is that you have ASP .NET objects stored in your session, which will stay there as long as the session timeout period configured in IIS.

Because HTTP is a character-oriented protocol, you should probably expect to see mostly string objects when profiling ASP .NET, because just about everything needs to be converted to a string before it's rendered as HTML and sent to the client. The sheer number of string objects is going to make it seem that it would be difficult to track down any problems. What I tend to concentrate on are the objects that would be holding references to these strings, so a top-down analysis of the data would be preferable to a bottom-up (starting at one of your gazillion string objects and navigating the hierarchy upwards). For example, looking at the System.Web namespace and finding the state bag objects or HttpSessionState collections will probably lead you to large collections of strings -- then you can probably work out why they are still live, then either do something in the ASP .NET code or take administrative action like decreasing the session timeout period.

Hopefully this gives you some ideas.

Rim Shot

What I need is unrelated to web pages.

I was focusing on the first line of the original post:

I am interested in knowing the order of function calls and events.

I am describing is new functionality that (I think) could be easily added to the profiler.

I need a tool that is similar to a profiler, in that it monitors execution, but instead of telling me how long each line takes to execute, it shows what lines were executed. I'm not talking about code coverage. I don't want statistics.

I want to see stuff that single stepping can't easily catch.

Imagine adding a trace statement to every line of code in the application, then turning trace log into a report that shows what happened--as shown in the flash demo in my previous post.

The tool would help to debug code that contains timers or properties that produce unexpected side-effects.

James Moore

Hi there,

Thanks for your post and some interesting thoughts. We are currently looking at the future of the profiler and posible functionality improvements.

I have forwarded your comments to our usability team for consideration.

Out of interest what sort of bug/problem would this functionality help you fix or understand? Understanding what you are trying to do will help us evaluate adding this sort of functionality better.

Thanks,

James

Rim Shot

Scenario #1 Timers
I have some code that has two timers.
They start in response to mouse movements.
It is not possible to single step through the code to see what is happening.
I have to form a mental model of the process, define hypotheses about the behavior I'm observing, then instrument the code to see if my hypotheses are correct. It can be enormously time consuming.

An execution trace would let me see what actually happened and eliminate a lot of the trial and error.


Scenario #2 Hidden side effects in generated code

I recently burned a lot of hours isolating a bug that was occurring at a seemingly unrelated line.
The line set a value in a DataRow.
When I touched the data row, the data set was creating a new row, causing unexpected behavior in a grid.
Commenting out the offending line only caused the problem to move to the next line that touched the data row.
The code that was executing was hidden from the debugger because it was generated code (with a DebuggerNonUserCode attribute).

An execution trace would have let me see that a new row was being created as a side effect of touching the data row--and that side effect was moving as I commented out the lines.


Scenario #3 Deferred detection of symptoms

Yesterday, I found an unexected line of test code that was refetching a data set. It was in a three line routine that should not have had anything to do with the problem. Since the effects were not felt until much later, I kept stepping right past it. If I had realized what was happening it would have been easy to find, but all I was seeing was that the data row associated with my grid row was magically null several levels up the call stack. Since I didn't know what was happening, I kept asking the wrong question and kept getting misleading answers. I needed a way to look at the execution from a high level and see where something unexpected was happening.
Instead, it took three days, and four developers to isolate it.

An execution trace would have shown me that something huge was happening as a side effect of calling that little routine.



Writing sample code to demonstrate these kinds of problems is not possible.
By definition, these problems are hard to isolate because they exist in complex scenarios, where the code may have been poorly constructed and is probably not well understood.

Just like a class diagram can make it easier to understand the structure of the code base, a graphical execution trace could make it easier to find unexpected behavior.

James Moore

Thanks for taking the time to write that. They all seem to make sense - the main case I could think for with this was execution order of events.

I can't promise anything right now (or any time that soon ) but we are discussing the future of the profiler at the moment so any comments to help us on our way are very welcome.

James

Rim Shot

This is what I need: http://www.replaysolutions.com/

Unfortunately, according to this New York Times article, it comes with a $50,000 per project price tag. Ouch!
http://www.nytimes.com/2008/03/23/technology/23proto.html?_r=1&scp=1&sq=game+software+bugs&st=nyt&oref=slogin.