Development of a memory analysis tool as a plug-in for an IDE

Requirements

One of our Japanese customers required a memory analysis tool to be developed as plug-in to their IDE. The plug-in should be developed as a DLL confirming to the plug-in specifications of the IDE. The plug-in should use a command-line tool to get the analysis results and then display it in GUI. The plug-in should take an object file as input. The plug-in should implement the following windows on the IDE:

1. Call graph window
2. Function list window
3. Memory view window
4. Many operations involving data manipulation had to be implemented for each of the windows.

Challenges

• Multi-threading
• Manipulation of call graph
• Testing GUI

Solution

• Environment

  OS	Windows
  Language/Platform	VC++ using MFC
  Development model	Incremental development model
  Quality validation tools	Numega Dev Partner Studio to check for memory errors and memory leaks

• Features

  • Call graph options
  • Add function to call graph
  • Remove function from call graph
  • Display recursive call chains
  • Display accumulated stack size of call chains
  • Drag and drop to rearrange call graph
  • Set a limiting stack size. Call chains whose accumulated stack size exceeds the limiting size will be highlighted
  • Display of sections in the object file and its sizes
  • Display of functions and its stack sizes
  • Drag and drop across windows

• Description

  The first step we did was to make out a detailed functional specification which covered all the requirements unambiguously. Then we designed a module that can spawn a console process and establish pipes for communication with the process. Then we decided on a set of commands to be given to the command-line tool to get the analysis results required for the plug-in. The output of the command-line tool is then fed to a parser which extracts the information from the output of the command-line tool and provides data to GUI.

  The call graph window as required by the customer was a custom control which is a hybrid of a listview and tree control. In MFC, if the controls provided by default are used, it is easy. It becomes complicated when such custom control have to be created. We referred to samples on the internet to get the control implemented.

  The next challenge we faced was the complex data manipulation of call graph. Call graph is a recursive graph. Adding / removing functions to call graph may result in recursion or may remove an existing recursion. Also when a function is added as a caller to a specified callee, it should be added at all instances of the callee. It is the same case for removing a function also. We had to cover lot of cases regarding call graph manipulation as compared to what we visualized earlier. This increased the development and testing time. But this time was made up as other modules were developed earlier than schedule.

  The next challenge was multi-threading. The plug-in had an option to stop the process while processing the input file. This means that all the operations in the plug-in had to be run using a separate thread; so that it can be stopped as required. The plug-in had 3 major operations:

  1. Spawn command-line tool and get its output
  2. Parse the output of command-line tool
  3. Display the results in GUI

  Implementing the above tasks as thread and synchronizing the threads was not a trivial task.

  Another stage where we faced problem was during testing. Since the plug-in supported a variety of options in GUI, each of them had to be tested under different input conditions. There is no systematic automated way for GUI testing. So testing conditions were defined and testing was done manually. More time was spent on testing and verification of test results.

  The project was completed and the pug-in delivered to the customer on time