Debugging with QC

Stress your software, not yourself

By Jeremy Vineyard

Introduction

The Memory Manager is one of the most commonly used components of the Mac Toolbox. Most applications are continually allocating and releasing memory - loading windows, pictures, and other resources, locking them, relocating them, resizing them, and purging them when they have served their purpose.

With all of this activity in memory, it is easy for a programmer in a hurry to overlook sections of code that could cause unforeseen problems for users. Attitudes like, “This memory operation will never fail”, and, “It’s only a small memory leak”, frequently lead to software that crashes, frustrating the user to the point of switching to your competitor and advising associates not to buy your product.

Because the Memory Manager is so crucial to any Mac application, it is crucial to ensure that the use of the Memory Manager is solid. The problem is that, most of the time, the effects of memory-related bugs are seen long after the bug occurs, making tracking them down a difficult and time-consuming task.

Thankfully, there is a tool available that makes preventing and tracking down hard-to-reproduce memory-related bugs easier. This is QC (as in “Quality Control”), a low-level debugging tool for use with the Mac OS Memory Manager.

Figure 1. QC Control Panel

Setting Up and Using QC

QC requires System 7 in order to run. It is developed by Onyx Technology and costs around $100. QC is copy-protected and will allow you to run only one serialized copy at a time on a network. Additional serial numbers are available by buying additional copies of QC.

QC consists of a control panel, on-line documentation, and a set of C APIs. All interaction with QC is done in the control panel.

QC can be set up to run tests and suites of tests on a “target” or “target program”. Target programs don’t have to be applications; they can be other executable code such as control panels. Test suites include tests that validate blocks of memory, tests that detect common Memory Manager errors, and tests that stress the application heap to ensure that the application code runs properly under difficult memory conditions.

How Does It Work?

Unless you are using the API, QC performs all of its tests by patching traps. QC will only report errors related to the tests that have been enabled for the target program, and it will not report errors when it is not running. QC reports every error with a _DebugStr call which will drop into MacsBug or your high-level debugger if it is set up to do so. In addition to reporting the error, QC reports the address of the last trap called in your code before the error occurred, allowing you to trace through the code to chase down the bug.

QC can automatically launch itself along with your target. You can choose to have QC launch when the target program calls _InitGraf or when a certain resource is loaded. Making QC wait until a resource is loaded is useful for non-applications such as control panels that will not call _InitGraf.

A key combination can be set that will launch and unlaunch QC while the target program is running. QC will pick the correct set of preferences for your target program when it is launched. As soon as QC is launched, the tests it performs are in progress.

Some tests in QC cannot distinguish when an error has occurred in an application other than the program being tested. It is therefore best to test your target program with only itself and the Finder running.

If you have all of the tests enabled, the slowdown caused by QC is quite noticeable, so be prepared. However, this is to be expected from such a low-level debugging tool, and is bearable.

Memory Validation Suite

QC offers a suite of tests that validate the Memory Manager structures themselves, rather than the use of those structures. These tests are valuable for tracking down corrupted or incorrectly specified data.

The first test in the validation suite, Cross-reference Master Pointers, looks at all relocatable blocks in the heap (handles) and makes sure that they are pointed to by a master pointer within a non-relocatable block. This test can catch orphaning of relocatable blocks and corruption of the master pointer list.

The Validate Handle/Pointer test verifies that each handle/pointer is pointing to a block of memory with the correct properties (locked/unlocked for a handle, non-relocatable for a pointer) as they are passed to Memory Manager calls.

Memory Manager Misuse

QC provides the programmer with a series of tests that detect common misuses and mistakes made while using the Memory Manager. It is the commonness of these problems that makes these tests so useful in debugging code.

Activating the Detect Write to Zero test checks, on each trap call, as to whether your target program has overwritten location zero. QC cannot determine whether it was your target program or another running application that overwrote zero, so again it is best to test with as few applications open as possible.

The Dereferencing Zero test puts data into location zero that will cause a bus error when a nil pointer/handle is dereferenced by the target program (a very common mistake).

Reasonable Allocations checks to make sure that allocations of data with _NewHandle, _NewPtr, etc., are passed reasonable values for the data size. Unreasonable allocations might include a negative data size or a data size that exceeds the size of the application heap.

QC’s ability to detect when a resource is disposed of incorrectly with _DisposeHandle or a handle is disposed of incorrectly with _ReleaseResource is a very useful feature. This is probably one of the mistakes most easily made by Mac programmers when writing code that uses both handles and resources. Enabling this test almost immediately showed me places in my (untested) code where I wasn’t releasing resources with _ReleaseResource, causing memory leaks and a possibly damaged resource map.

BlockMove Checking checks the values passed to _BlockMove to make sure that all addresses and data sizes are valid. With Block Bounds Checking enabled, QC adds a small tag value to every allocated block. QC periodically checks to see if this tag has been overwritten and reports an error if so. This is useful in catching errors related to writing past the boundaries of an array or a block of data.

MemErr Detection is a warning test that reports an error every time the low-level global MemErr is set to be anything other than noErr. This does not mean that the code is bad, but it can alert the programmer to places in the code where failed memory operations are not handled correctly. Grow Lock warns about attempts to resize a locked relocatable block. Grow Non-Reloc reports attempts to change the size of a pointer. Both of these operations are very likely to fail if a locked or non-relocatable block is ahead of the block being grown larger, but, as before, this may not represent an error if it is handled correctly in the code.

Scrambled Heaps

Many times, a program is written, tested, and approved under ideal memory conditions, but when someone else uses the software with a lowered memory partition and several other applications running simultaneously, the program cannot handle the stress. It can be difficult to simulate these stressful conditions if you don’t know what to look for. Of course, you can always lower the application memory size yourself and launch several other applications every time you test your own program, but this is a difficult solution at best. QC offers a seamless method of ensuring that all of your code will continue to operate under even the most stressful memory conditions.

Scramble Heap continuously moves all relocatable blocks of memory. If you use a pointer to point to the data represented by a relocatable block and that block is moved in memory, your pointer will no longer be valid. Scrambling the heap is a good way to make sure your code handles this possibility.

Purge Heap will purge handles marked as “purgeable” whenever possible. This is a useful tool for detecting sections of your code where you did not think it possible for a handle to become purged, but it has. This is a likely situation if you have always tested your application with lots of extra memory, but the user lowers the memory partition.

Check Heap checks the structure of the heap before every Memory Manager call to ensure its reliability. Invalidate Free Memory fills all free blocks with a value that will cause a bus error if dereferenced by the target program. This will prevent you from accessing a block of data that has been released from memory.

QC API

The QC API provides a set of routines in C for accessing directly from the target program code the individual tests that QC is able to perform. This is useful for making a special “debug” build of a product that routinely checks for memory-related errors near crucial portions of code.

Any of the tests that can be enabled from the QC control panel can also be enabled with the QC API. QC must be installed for the QC API to work.

Conclusion

QC is ideal for small developers who don’t have the resources to write tools to extensively stress-test their products. Larger developers are more likely to have their own customized stress-testing tools, but QC may fill the gap for those memory-testing features that are missing.

If you are a small developer who doesn’t have the time to track down memory-related bugs after your product ships, QC is worth the money. Buy it. If your program has problems, QC will alert you to them and will protect you from being embarassed by unforeseen glitches in your code. If your program is spotless, QC will provide you with that needed bit of extra security (and extra sleep) when your product is shipped. For only $100, it is a worthwile investment in the quality of your products and the satisfaction of your customers.

MacTech’s resident programmer, Don Bresee, adds: “QC gives you the ability to consistently reproduce the nastiest of bugs, which is always the first step to finding bad code. QC immediately helped me find a bug in THINK Reference that was no less than four years old.”