Advanced LabVIEW Debugging: Profiling VI Execution with the Desktop Execution Trace Toolkit

This article is part of a series on software engineering practices and tools for large application development in LabVIEW. Click here to view the list of other articles

Identifying the source and fixing the cause of unexpected or undesirable behavior in software can be a tedious, time-consuming and expensive task for developers. Even code that is syntactically correct and functionally complete is often still contaminated with problems such as memory leaks or daemon tasks that can impact performance or lead to incorrect behavior. These oversights can be difficult to reproduce and even more difficult to locate, especially in large, complex applications.

LabVIEW developers can take advantage of a number of tools for a combination of static and dynamic code analysis to screen for problems and isolate their cause.  These tools can reduce the time spent tracking down problems, while providing more exhaustive and complete analysis of the software.  This article will provide an overview of the Desktop Execution Trace Toolkit and how it can be used for dynamic analysis of LabVIEW applications.

To learn more about other software engineering tools that are available for LabVIEW, please visit ni.com/softwareengineering

Introduction to Code Analysis Techniques

A formal code review is an important and common practice for software engineers seeking to mitigate the risk of unforeseen problems, identify the cause of bugs that are difficult to find, align the styles of multiple developers, and demonstrate that the code works.  These reviews are an opportunity for a team of qualified individuals to scrutinize the logic of the developer and analyze the performance of the software.

Manual reviews can quickly prove to be time and cost-prohibitive for large applications; therefore, tools for static code analysis, such as VI Analyzer, are typically used to examine source code and proactively seek out potential problems.  Once problems are identified, dynamic code analysis tools, such as the Desktop Execution Trace Toolkit, are valuable for gaining low-level insight into the execution of code and helping developers locate the cause.

• Static code analysis refers to any tool or method that has pre-established criteria by which it can compare source code to see if it meets standards for style, organization and technique.  This can be performed prior to, or even without, compilation or execution of the application.
• Dynamic code analysis refers to the ability to understand what software is doing ‘under-the-hood’ during execution.  In other words, it provides details about events and the context in which they occur in order to give developers a bigger picture and more information that can help solve problems.

Knowing When to Use Dynamic Code Analysis to Trace Execution

Dynamic code analysis has a number of different use-cases throughout the software development life-cycle, including:

• Detecting memory and reference leaks
• Isolating the source of a specific event or undesired behavior
• Screening applications for areas where performance can be improved
• Identifying the last call before an error
• Ensuring the execution of an application is the same on different targets

While all of the mentioned use-cases are appropriate, it is perhaps the most useful to know exactly what you’re looking for or where you’re looking for it.  This makes it easier to sort through the information to find details that can help address your specific concern.

Tracing a LabVIEW Application

The Desktop Execution Trace Toolkit is a stand-alone application that can be installed with or without the LabVIEW development environment.  However, it does integrate with the Project Explorer if installed on the same machine to enable automated configuration of traces.

To launch the Desktop Execution Trace Toolkit from within LabVIEW with an automatically configured trace, right click on ‘My Computer’ from within the Project Explorer and select ‘Trace Execution’ from the menu that appears.  When the Desktop Execution Trace Toolkit opens, it will already be setup to monitor any and all VIs in that Project Window during execution.

Figure 1: The Desktop Execution Trace Toolkit can be launched from within the LabVIEW Development Environment by right-clicking on 'My Computer' and selecting 'Trace Execution.'  This will automatically configure the toolkit to trace the current Project.

Alternatively, users can configure traces themselves from within this tool by selecting ‘New Trace’ from the menu at the top of the screen.  From this dialog, users can select ‘Local Application Instance,’ ‘Remote Application Instance,’ or ‘Application or Shared Library.’

Figure 2: Selecting 'New Trace' in the Desktop Execution Trace Toolkit reveals this dialog, where you can select either a local or remote applicaiton instance to monitor

The first option, ‘local application instance,’ is for tracing an application on the same machine within the development environment.  Selecting this option should list all the currently active LabVIEW Projects that are open.  The Desktop Execution Trace Toolkit can also be used to monitor remote systems over a network, as well as executables and shared libraries.  These can also be configured from this dialog and are described in greater detail in the following section.

Tracing Deployed Systems and Remote Targets

Problems such as memory leaks can have costly consequences for systems that are required to sustain operation for extended periods of time or for software that has been released to a customer.  If software that needs debugging has been deployed and the LabVIEW development environment is not installed on the current machine, it may be beneficial to perform dynamic analysis of the code with the Desktop Execution Trace Toolkit over the network.  For deployed systems, even if the development environment is available, it may be impractical or difficult to locally troubleshoot or profile the execution of a running system. 

[+] Enlarge Image

Figure 3: The Desktop Execution Trace Toolkit can monitor remote VIs, executables, and shared libraries via a network connection

When developing an application that will be remotely monitored, you must enable network communication with VI Server from the options menu.  For remote tracing of a VI in the development environment, make sure that the TCP/IP communication is turned on and select a port that is not currently in use (default is 3363). You’ll also need to ensure that machine access is enabled for the terminal where the Desktop Execution Trace is located.  For remote tracing of an executable or shared library, you’ll need to enable debugging from the build specifications menu and ensure that the VI Server port is available. 

To connect from the Desktop Execution Trace Toolkit, select either ‘remote application instance’ or ‘application or shared library’ from the ‘new trace’ dialog.  Specify the IP address and the port on which VI Server is accessible, and select the instance from the list that appears.

Figure 4: Specify the IP address and Port of the remote application instance to trace

For more information on how to setup remote tracing, click here to see the Desktop Execution Trace Help

Configuring Traces

Before starting a trace, you can configure the tool to only record certain types of events.  Click ‘Configure’ on the toolbar to select from all the different type, and specify details such as the minimize size required to capture a memory allocation.

Understanding the Trace Data and Creating Filters

After clicking ‘Start’ on the toolbar, the main view of the Desktop Execution Trace Toolkit enumerates every event in chronological order as the tool receives trace data.  This view shows the time at which the event occurred, the name of the VI that fired the event, the type of event that was fired, the thread Id that it was assigned to, and any appropriate details.  Clicking on an event displays additional information in the panel below the table, including the call chain that led to this event and the number of the core that the process was actually executed on.

[+] Enlarge Image

Figure 5: Highlighting an event from the table reveals additional information in the dialog below

Double clicking certain events when profiling instances that have access to the block diagram will highlight the object on the block diagram that caused the event.  For example, if you detect an un-handled error, double clicking the event in the table will highlight the VI as shown below:

Figure 6: Double clicking an event in the table highlights the corresponding object on the block diagram

It is important to keep in mind that a large application will result in a proportionate amount of data about run-time behavior when performing dynamic code analysis.  For this reason, it may be useful to create a filter to help wade through large amounts of data and target specific events or VIs.  To setup a filter, click on the ‘configure filter’ button on the toolbar above the table.

Figure 7: Because of the amount of data returned by large applications, it is often beneficial to create custom filters using this toolkit

Since filters are applied to events after they’ve been received, the numbering of events is unchanged and will show gaps where other events have been filtered out.

Summary

Debugging code is a time-consuming and difficult task for developers.  When software exhibits unusual or unexpected behavior that is not easily explained, dynamic code analysis with tools like the Desktop Execution Trace Toolkit can help detect and isolate the cause of these problems.

Related Links

Desktop Execution Trace Toolkit Product Information

Software Engineering Best Practices for LabVIEW

Software Engineering Tools for LabVIEW

Large LabVIEW Application Development Resources

Large LabVIEW Application Community

Performing Validation and Automated Software Testing in LabVIEW

 

Reader Comments | Submit a comment »