Can you start and stop boundschecker (DevPartner)?

Question

I'm trying to use boundschecker to analyze a rather complex program. Running the program with boundschecker is almost too slow for it to be of any use since it takes me almost a day to run the program to the point in the code where I suspect the issue exists. Can anyone give me some ideas for how to inspect only certain parts of my software using boundschecker (DevPartner) in Visual Studio 2005?

Thanks in advance for all your help!

Answer 1

I last used BoundsChecker a few years ago, and had the same problems. With large projects, it makes everything run so slowly that it is useless. We ended up ditching it.

But, we still needed some of it's functionality, but like you, not for the whole program. So we had to do it ourselves.

In our case, we mainly used it to try and track down memory leaks. If that's your objective as well, there are other options.

1. Visual Studio does a pretty good job of telling you about memory leaks when your program exits
2. It reports leaks in the order that they were created
3. It will tell you exactly where the leaked memory was created if your source files have this at the top

#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif

Those help a lot, but it's often not enough. Adding that snippet everywhere isn't always feasible. If you use factory classes, knowing where memory was allocated doesn't help at all. So when all else fails, we take advantage of #2.

Add something like the following:

#define LEAK(str) {char *s = (char*)malloc(100); strcpy(s, str);}

Then, pepper your code with "LEAK("leak1");" or whatever. Run the program, and exit it. Your new leaked strings will display in Visual Studio's leak dump surrounding the existing leaks. Keep adding/moving your LEAK statements and re-running the program to narrow your search until you've pinpointed the exact location. Then fix the leak, remove your debugging leaks, and you're all set!