Improvements to the Desktop Execution Trace Toolkit

[jdoyle]

I hope this is the correct venue for ideas about the desktop execution trace toolkit.  It is a LabVIEW-related tool.

In the course of investigating several LabVIEW crashes, one of NIs AEs suggested the DETT.  This seemed like a really good idea because it runs as a separate application and therefore doesn't lose data on the crash.  Better yet, the last thing in the trace would be likely to be related to the crash.  So I started my eval period of the DETT.  I am debugging a LV 8.6.1 program but since I have installed LV 2009, the 2009 version of DETT came up when I started tracing.  It seemed to work, however.

Sadly, the DETT sucked.  After about a minute of tracing, it got buffer overflow and popped up this dialog:

When I dismissed this, I got the usual popup about "Not enough memory to complete this operation."  Following this, the DETT was basically frozen.  I couldn't view the trace, specify filters, nothing.  I had to restart the application.  I tried a few hacks like disabling screen update while running, but nothing changed.  The DETT app was using about 466 MB at the time, and adequate system memory was available.

Possibly this is a stripped-down eval version.  If so, it is a mistake to make an eval  version work so badly that one is pursuaded not to buy the full version, which is the way I feel now.

I have some suggestions about how to improve the tool.  If these are implemented, I would recommend that we buy the full version.

1. Stop barfing when the buffer overflows.
2. A wraparound (circular) buffer should be an option.  Often one is interested in the latest events, not the first ones. 
3. There should be a way to specify an event as a trigger to start and/or stop tracing, like in a logic analyzer.  Triggers could be an event match, VI match, user event, etc.
4. The tools for analyzing events in the buffer (when it doesn't overflow) are useless. A search on a VI that is obviously present fails to find any event for that VI.  Searching should be able to be done based on something like the trigger mentioned above.
5. The display filter is a good start but needs to be smarter.  It should be possible to filter out specific patterns, not just whole classes of events.
6. The export to text is broken.  It loses the name of the VI that has a refnum leak.
7. Refnum leak events are useless.  They don't give even as much as a probe would show, like what the refnum is to, the type, etc.
8. The tool should be able to show concurrent thread/VI activity side-by-side, not serially, so one can see what is happening in parallell operations.

Do this stuff and you will have a useful tool.

John Doyle

[Intaris]

Well this isn't really the right place for this, it would be better off in the NI forum under the LabVIEW heading.....

[brahe]

John,
 
Those are very good suggestions and just the type of feedback we're looking for improving the tool. 
 
1,2.
I agree that a circular buffer is a good idea.  The current implementation keeps all the traces in memory in order to keep up with the potential fast rate of events generated.  There's a setting in the TraceTool.ini file (MaxEvents=4000000) that specifies when the tool will stop tracing due to too many traces.  Apparently, you run out of memory before this limit is reached. 
 
Another idea we have to get around this problem, is to trace directly to a file and then later read this file back to analyze the events.
 
3.
Good ideas on doing triggering on events.  We also have looked at adding a start and stop primitive that you place on the diagram and tracing will start and stop when those are encounterd.
 
4.
This sounds like a possible bug.  I'm not able to reproduce this currently, but will look further into it.
 
5.
There are many improvements we would like to make to the filtering, for example, the ability to save and load a specific filter setting.  Your idea is a great one too.
 
6.
I'm not able to reproduce this.  
 
7.
Regarding the leaked refnums, you can "double-click" on the event and you would see where the reference was opened up.  In the detailed section you should also see the number itself and can search for this to see where it was used.
 
8.
The tool is set up to have more than one way to display the data.  Currently the only view is the chronological table, but we have ideas of adding other views.  For example, a graphical view that would show parallel operations.  Other ideas include views organized per VI, or threads etc.  Once can then jump from a specific event in one view to the same event in another view to better understand what's going on.
 
Thanks for the feedback,
 
-tycho
 
 

[jdoyle]

Tycho,

Thanks for taking a look at this.  Tracing to a file sounds like a good option, but it must be only an option, because the I/O latency could affect the picture, and would have, in the case I was dealing with.

Thanks for telling me about the .ini settings and the double-click trick.  I did not know about them.  Unfortunately, my eval period is up and we're not likely to buy a license without a more encouraging evaluation experience.  The problem I was looking at has been sort of solved for now, but the next time I think I need tracing, I'll try to evaluate this tool again.  I certainly think that when it becomes a little more mature, it will be a useful tool.

John Doyle

[Elijah_K]

John,

We'd be happy to extend your evaluation period so that you can re-evaluate the Desktop Execution Trace Toolkit. I would encourage you to evaluate the 2009 version, which resolves many of the issues in the first version. You should still be able to trace applications running in 8.6.1.

Please contact me at Elijah.Kerry@ni.com if you're interested in an extended trial period.

Thanks,

Eli

[Daklu]

I especially agree with #5.  Recently I ran a trace on an application and wanted to filter out all the Dequeue:Timeout events.  I was disappointed to discover I don't have the much control over the filter resolution.

Another BIG usability suggestion:

Make it possible to scroll through the trace window using the mouse wheel.

[LVB]

Tracing directly to a file to avoid the "Not enough memory to complete this operation". would be an excellent feature.

This would allow debugging applications that slow memory leaks and other issues that occur over a long period of time.  This use case does not work well with the current limitations of the DETT.

[wideofthemark]

Has there been any update on this.  I have the DETT 2011 and still it doesn't seem to either have a circular buffer or trace to file - unless i'm being dumb