Error Detection with BoundsChecker

From Apache OpenOffice Wiki
Jump to: navigation, search


BoundsChecker is a utility for checking applications for bugs like memory overwrites, reading not initialized memory, use of dangling pointers and much more.

BoundsChecker is available for all Windows platforms. If you don't have a licensed version yet, you may download an evaluation version from

I recommend using BoundsChecker version 7.0 or higher, because they improved the detection of memory leaks and BoundsChecker doesn't report so many wrong memory leaks because of dynamically allocated memory in static objects in libraries.

For integration into Visual Studio 2008, version 9.0 is needed, and for Visual Studio 2010, version 10.0 is required.

For X64 applications, you will need version 10.5.


Install the lasted version of, non product builds are preferred for receiving complete stack traces.

Without stack traces, beside that you may need them for debugging, you can't set error suppressions on specific methods.

An other advantage of non product builds is, that some more objects are destroyed on application exit. This is normally not necessary, but it's important for finding memory leaks, and therefor only done in non product builds. has it's own memory manager in the project sal. This should be disabled by building sal/rtl/source/alloc_global.c with dmake ENVCFLAGS=-DFORCE_SYSALLOC. Copy sal3.dll to the URE/bin directory.

I didn't try if new releases of BoundsChecker works well with our own memory manager, maybe with the option 'Show leaked allocator blocks'.

Installation of BoundsChecker

Install BoundsChecker standalone or as part of the DevPartner Studio (administrative rights are required).

If you want to compile something for BoundsChecker ("FinalCheck"), you need to have nmcl.exe in your PATH (e.g. C:\Program Files (x86)\Common Files\Micro Focus\NMShared\CTI\10.5)

BoundsChecker can be used via integration into Microsoft Visual Studio or stand alone. For debugging purposes, using the Visual Studio integration is recommended.

Recommended BoundsChecker settings

Configure BoundsChecker via 'BoundsChecker/Settings...' in Visual Studio, or via 'Program/Settings...' in the BoundsChecker application.

For a complete description of all possible settings see BoundsChecker documentation, these are only some recommendations on how to configure BoundsChecker for testing

The defaults for 'General' setting are good, may be you want to reduce stack sizes for using less memory and for better performance.

'API Call reporting', 'COM Call reporting', 'Call Validation' and 'COM Object Tracker' can stay off.

You should also turn of 'Resource Tracker'.

'Resource Tracker' and 'Call Validation' might be reasonable only in some projects using the Windows API directly, like VCL.

'Memory Tracker' stays enabled.

Turn of 'Report leaks immediately', because some objects register itself somewhere and BoundsChecker reports a lot of wrong memory leaks.

'Enable FinalCheck' should stay enabled for better results.

Turn on 'Enforce strict reallocation semantics' for marking pointers as dangling after a realloc, see BoundsChecker help for further information.

If you are searching for a strange error you can't find with normal settings, you may chose 'Check heap blocks at run time - On all memory API calls', but then will become *very* slow.

Working with BoundsChecker

You need to run soffice.bin directly, instead of soffice.exe. This is possible when you extend your PATH variable to contain the Base/program and JRE/bin directory. Adding the brand layer program dir is not necessary.

Searching for memory leaks

If you only are interested in searching for memory leaks, you might disable 'FinalCheck', 'Guard bytes', 'Fill on allocation' and 'Poison on free' on the 'Memory Tracker' page for better performance.

You don't have to instrument any code for this.

After starting and closing the application you can investigate all memory leaks on the 'Memory Leaks' page in the BoundsChecker window.

Searching for errors

You can search for errors without instrumenting the code, but in this mode BoundsChecker will miss a lot of different kinds of errors, so it's highly recommended to instrument the modules you want to test. For further information which errors are only detected with FinalCheck, see BoundsChecker help file, "Checking a Program with FinalCheck".

Compiling with BoundsChecker

The build environment offers some dmake parameters for instrumenting modules with FinalCheck:

   bndchk=true           Use BoundsChecker instrumentation

    [nmpass=true]        pass-through mode, code will not be instrumented.
    [stoponerror=true]   Stop if an error occurs during instrumentation.

When using bndchk=true, all output file are build into <output tree>.bnd, so you should rename the existing output tree before building some files for BoundsChecker.

If you have some files you don't want to instrument, maybe because they lead to runtime problems with BoundsChecker, you can specify nmpass=true, so files are compiled into the BoundsChecker output tree, but without instrumentation.

If a file can not be instrumented, it will be compiled without FinalCheck automatically. Use stoponerror=true if you want to stop the build process in this case.

General hints

If you are only interested in errors in your module, not in memory leak detection, it might be a good idea to use a product build of for better performance, but then stack traces are limited to modules that are at least linked with debug information.

For error detection its better to use BoundsChecker integrated into Visual Studio, than using BoundsChecker stand alone, because only in the integrated version you have a 'debug' button in the error dialog to immediately start debugging when an error occurs.

Depending on the reported error, you find different call stack in the error window. Use the tab control to switch between 'Current Call Stack', 'Call Stack At Allocation' and 'Call Stack At Deallocation'.

There different kind of errors and the possible reasons are well explained in the BoundsChecker help, just press the 'Explain' button in the dialog.

If you are not interested in some errors that occur very often or don't belong to the module you want to investigate, you can use the error suppression.

You can suppress this kind of error always, but better is to suppress it only when occurring in a special function or at least a special module or file.

BoundsChecker offers the possibility not to check special modules (Settings/Modules and files), but this can lead to problems and not detected error.

You can't disable the sal library, because memory allocation is done there, and when this is monitored there is no big different if you turn of some other modules, the memory operations are the most expensive things for BoundsChecker.

Start Script

Change _NT_SYMBOL_PATH and _OFFICE_ROOT as needed

 @echo off
 set _NT_SYMBOL_PATH=O:\DEV300\\pdb.m37
 set _OFFICE_ROOT=e:\openofficeorg30\ 3
 set PATH=%PATH%;%_OFFICE_ROOT%\Basis\program
 "C:\Program Files (x86)\Micro Focus\DevPartner Studio\BoundsChecker\BC.exe" "%_OFFICE_ROOT%\program\soffice.bin"
Personal tools