LabVIEW Idea Exchange
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.
- Stop barfing when the buffer overflows.
- A wraparound (circular) buffer should be an option. Often one is interested in the latest events, not the first ones.
- 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.
- 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.
- 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.
- The export to text is broken. It loses the name of the VI that has a refnum leak.
- 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.
- 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
