line-level times are not showing

adbourdages

Good day,

I have done two profiling sessions. In one I have all the line-level information in the source code view and in the other I only have method-level information.

They were both recorded using the same project, one lasted ~20 sec while the other one lasted ~15 minutes.

How can I get ANTS to display the line-level data on longer profiling sessions?

Alain-Daniel

swythan

I'm having the same problem yesterday (on an eval license). I'm just getting the timings for the whole method displayed next to the first (executable) line in the source.

Any hints for debugging the issue?

StephenC

Hi,

sorry for the trouble you are having. There have been a couple of reports of this but we don't have very much information as yet about what might be the cause of it.

Can you please double check that you have selected the line level timing mode from the opening project dialog. I did have one report and it turned out he had changed the setting and forgotten so i want to rule out the most obvious before we proceed.

Can I ask:

1) what type of applications are you running
2) Framework versions
3) Visual Studio version
4) Does this happen with all of your applications?
5) Is there anything different about the applications in which it does happen with?

If at all possible you can create a small "Hello World" style application that demonstrates the issue that would be great. You can send it to support@red-gate.com and reference this post.

Regards,

Stephen

adbourdages

I have the standard version, so there is no other option than line-level!

1) It is an asp.net application, profiled on Cassini, using EntityFramework and NHibernate.
2) 3.5
3) Team 2008
4) I've tried with the only one application I'm working on. Can't help here.
5) n/a

I saved the profiling results. If they can be useful, tell me where I can send them. It is 75M.

To further help you out and clarify what is happening: If I profile the project twice, once with lots of request, the other only with a few, the small profile will have all the line-level data but not the large one.

I'll try to create a small application as you mentioned, but since your development team hasn't been able to reproduce the error (as you imply), I doubt I'll have any success.

Do you have an estimate on how long it will take to fix? (days, weeks or months?) Because right now, it makes ants pretty useless and I have to decide if I wait for the fix or move on to other tools/solution. I would appreciate if I can get an answer to this.

Alain-Daniel

swythan

My problem seems to have been running unit tests through the MbUnit GUI. (I was doing a quick demo of ANTS to a colleague.) Running the same tests through the MbUnit console works fine. Maybe it's something to do with the MbUnit GUI running the tests in a different AppDomain?

This is using Vista or XP, .Net 3.5 SP1, VS2008 SP1 (not used during test) & MbUnit 2.41.232.0.

StephenC

We discovered an issue with NUnit a while ago where the PDB files were not being shadow copied along with the other files. It resulted in the same sort of behaviour you are describing.

The work around for NUnit was to obviously turn off shadow copying but i'm not sure if this is possible with MbUnit. You could try manually copying the PDB files to the directory where the files are being copied to and give that a go as long as the directory isn't being cleaned when the files are being copied.

It shouldn't have anything to do with AppDomains.

Stephen

swythan

Cheers, Stephen.

Alain-Daniel: Sorry for hijacking your thread. It looks like your issue is more complex than mine!

StephenC

James, sounds like the issue you were having has been resolved (or at least to an extent). I know some one very involved with the MbUnit project and will try and confirm with him what's going on.


Alain-Daniel,

if you could give me some more details about the scenario and settings etc... we will try and get to the bottom of it too.

Maybe a screen shot would be helpful as well.

Regards,

Stephen

adbourdages

Hi,

I am not using any kind of test environment setup, simply running the website in Cassini and interacting with it in IE.

You can see the setting I use to start the project:
http://71.6.196.213:82/ForRedGate/settings.png

and the source code view:
http://71.6.196.213:82/ForRedGate/line-level-without-time.png

I know that if I drill down far enough in a call tree that the interface will start telling me that 'Simplified stack traces'. Maybe you are shedding the line-level times when you reach that point?

I don't know what to say, if you have any specific data you want, I can sent it. Actually, let me just put that profile result file out there for you to load:

http://71.6.196.213:82/ForRedGate/adb-profile.zip

Alain-Daniel

StephenC

Hi,

regarding the 'Simplified stack traces'. If you go to 'Tools' -> Options; before starting profiling and then uncheck the "Simplify very complex stack traces to save memory" option you won't get that in the tree view. It may however lead to higher memory usage while profiling.

Thanks for the info, we will try and get to the bottom of this and will post back with more questions or things to try when there are some ideas of what may be causing this.

Stephen

JasonC

Can you please also ensure that debug="true" in your web.config? This is necessary for line-level timing.

MikeW

Has this been resolved... I am having this issue with version 4.1, SOMETIMES it will show the line-level times and (with the same setup) sometimes it wont. It seems after stopping and compiling the asp.net app again it gets flaky, if it even worked to begin with. It appears to show method level timings even though it explicitly says "Line-level Timings". Things to note, this is a .Net 2.0 website, VS2005, Vista64

Brian Donahue

I don't believe that we have identified any "bug" that would cause the line-level to work sometimes and sometimes not.

It may be useful to know what you mean by "after stopping and compiling" the web app, as web applications are typically dynamically compiled. If you are doing a static compilation using aspnet_compiler.exe, the settings that you use may be wrong somehow.

MikeW

Its a standard visual studio web site compile, nothing strange about it... default settings. The site setup has 1 website, and 2 other project dll's that get compiled (as dependencies) along with it. To answer your question... and to make sure we don't focus on the wrong issue, "after stopping and compiling" was only referring to a case i ran into. That case being, It fired up and it actually ran the line-level timings and it all showed up correctly. After recompiling, it simply stopped showing line-level and appeared to show method level. This leads me to believe it has issues resolving the debug files. It seems the norm for me is that line-level hardly ever works, very frustrating. Now i will not rule out that im failing to do something very obvious maybe, but I cant seem to spot anything. Read above,and note that it does in fact read "Line-level timing", but it looks exactly like a method level report.

Brian Donahue

Surely this has everything to do with the PDBs and their availability and/or correctness. The whole mechanism for resolving source code is supplied by the Visual C++ runtime (far as I know) and we don't have much control over whether the source code location is turned over to ANTS Profiler by the runtime or not.

One thing that may make the process more reliable for you could be to, first of all, make sure that debugging information is generated for all builds, and that if you have to deploy the website files to a staging server, to ensure the PDBs are also copied to the right places. You could also consider creating some post-build events in Visual Studio to copy the PDBs to the "global" symbols location used by the VC++ Runtime.

MikeW

All of the PDB's are already grouped together in the website Bin folder along-side their respective dll's. Since Asp.Net website are generated on the fly with the aspnet_compiler (thats just how VS does it, alternately i could build it myself but with the same results), the resulting compilation is all put into another folder. Since this can be done over and over, the compiler attempts to be smart, renaming each new dll with some form of uniqueness (like MyFile.akwjedhaajd.dll for all ascx). I would imagine therein lies the problem. fyi, Line-level worked for me this last time i used it, but simply ceased to produce any results after i let the page sit, then tried a refresh. The graph showed activity, but selecting the new activity range, showed nothing at all, this is w/o compliling or anything. (i saw another thread on this somewhere here).

Brian Donahue

Hi,

Visual Studio does not do the compilation -- ASP .NET does. It creates temporary assemblies in the "Temporary ASP .NET Files" folder, but as long as the compilation mode is set to "debug" in the application's web.config, a corresponding PDB will be produced in the correct folder so this should always work with ANTS Profiler. If you have your own dlls that the web app references from your app_bin folder, these will need to be compiled as debug also and the correct pdb copied into the app_bin folder.

Regardless, you should always get results if you change from "only methods that have source" to "all methods". If you don't see anything then, and "hide insignificant methods" is off, then you have an entirely different problem. What it could be is that ASP .NET is recycling on you. This sounds like a possibility, if you have some results, and none after letting the application sit for ten minutes. The application could be timing out and the ASP .NET worker process exiting.

MikeW

As mentioned before, the pdb's are present in the app_bin.

As far as the timeout, your correct, but it should have fired up a new worker thread (or possibly snagged that last one depending on the pooling)... either way, Ants does show the activity but no code.

Brian Donahue

Can you try turning up the logging level to DEBUG and then see if there is any information in the logs about why it's not finding the source code?