By now, I felt I knew enough about Insure++ to do an example for this review. I selected a printed circuit layout program called pcb-1.3 in the apps/circuits directory of sunsite.unc.edu. (There is a newer version of pcb available.) This program consists of slightly over 600KB of source code, so it is a reasonably complex program, even though it is by no means huge. When compiling the program, Insure++ warned about several possible problems, but none of them looked too serious. I then started up pcb using the example data that came with it. I had no idea how to use the pcb software, so I just started clicking on things. (This is usually an excellent way to find bugs.) After a few minutes of playing with the program, I had six memory leaks and one NULL pointer evaluation listed in the Insra window (see Figure 1). At this point, I clicked on the error for line 1352 of the program action.c, and the screen shown in Figure 2 popped up. This shows the stack trace when the memory was allocated and when it was leaked. If you click on the red arrows, the indicated source code will be opened in your favorite editor. A quick look at the source code shows why Insure++ is complaining. In the function ActionSave on line 1290 of action.c, the program gets a file name from the user:
1289 case F_LayoutAs: 1290 name = GetUserInput("enter filename:", ""); 1291 if (name) 1292 SavePCB(name); 1293 break;
This file name is contained in memory set by malloc, pointed to by the variable name, a local variable in ActionSave. Later, at line 1352, we leave ActionSave:
1349 break; 1350 } 1351 } 1352 }There is no code in ActionSave to free the memory pointed to by name. When we leave the function ActionSave and the local variable name ceases to exist, there is no way to access this memory anymore—it has been leaked. Insure++ is warning us about this situation.
In addition to several memory leaks, Insure++ found a bug in the program related to using NULL pointers. It complained about this line:
I couldn't see anything wrong with this line by looking at it, so I restarted the program in the debugger, using the _Insure_trap_error breakpoint I mentioned earlier. When the program stopped, I examined the expression and it turns out that LineSortedByHighX[Layer] is NULL. The reason the program does not crash on this line is that we are taking the address of LineSortedByHighX[Layer][index2] rather than trying to dereference it. Presumably, at some later time, some function will evaluate this address and crash. Insure++ makes it possible to fix the problem and prevent a crash.
As you might be able to tell, I think Insure++ is a great product. It finds programming errors better than any other product I have used, it runs under my favorite operating system, and Parasoft's technical support is excellent. There is one problem—it's expensive. The cheapest configuration you can buy is a 3-user-node locked license, which costs $1,995 per node. Nothing I do on my home computer is worth that much money, so I won't be buying a copy of Insure++ for myself. I suspect that most people who program for fun will not be buying a copy either. Who should buy Insure++ then? People, or more likely companies, who do professional software development. When you are paying programmers several thousand dollars a month and bugs cost big money to deal with, then the price begins to look more attractive. When you consider that Insure++ might enable you to ship your product earlier, it begins to look very attractive. If you develop software for a living, you need this product. Insure++ runs under several flavors of UNIX and Windows too. In fact, anyone who is in an environment where programming time is money should consider evaluating Insure++. It is an excellent product.
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
- Optimization in GCC
- Using tshark to Watch and Inspect Network Traffic
- September 2015 Issue of Linux Journal: HOW-TOs
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python