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.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
2 min 49 sec ago
- Reply to comment | Linux Journal
4 hours 2 min ago
- Yeah, user namespaces are
5 hours 18 min ago
- Cari Uang
8 hours 50 min ago
- user namespaces
11 hours 43 min ago
12 hours 9 min ago
- One advantage with VMs
14 hours 38 min ago
- about info
15 hours 11 min ago
15 hours 12 min ago
15 hours 13 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?