Sad but true: most of the problems reported to MicroQuill tech support could be resolved by a careful reading of the SmartHeap Getting Started Guide (GSG) for the appropriate platform. If you do not have a copy of this document contact MicroQuill tech support and we'll email you an electronic version. Most of the following information is already in the GSG, but just in case you missed it:

1) If you link SmartHeap to a multithreaded app you must call MemRegisterTask before your app creates its second thread.

#include "smrtheap.h"
MemRegisterTask();

SmartHeap does not initialize its mutexes until this call is made, so failure to call MRT usually results in a crash. Note that if you link two or more modules in your app to the SmartHeap *static* library (libsmartheap_smp.a) you must call MRT in each module.

2) Generally, linking SmartHeap to your 'EXE' is the best way to ensure that the whole process will use SmartHeap for malloc/new. It then should not be necessary to *also* link SmartHeap to shared libs that are dynamically loaded by the process.

HPUX, Solaris and Linux users only: if your EXE is not linked to SmartHeap and you're linking SmartHeap to a dynamically loaded shared lib, you must specify the -B symbolic option to ld when linking the shared lib: otherwise the shared lib will bind to CRT malloc/new (thru the EXE) and SmartHeap won't be used.
Solaris users only: per Sun, -Bsymbolic is no longer an effective option. At present (Nov. 2006) the only workaround for this is to recompile the SmartHeap source files which define malloc and new (in your SmartHeap /source directory) with the -xldscope=symbolic option. Contact Microquill support for detailed instructions and updates.

3) We recommend using the Sun Workshop/Sun Studio compilers, but many SmartHeap Solaris users have had success using SmartHeap with the Gnu compilers as well: if you're using a Gnu compiler do *not* follow the instructions in the Getting Started Guide for working with an "unsupported" compiler. Just use the instructions for supported Sun compilers.

4) Note that the SmartHeap C++ definitions are bundled in a separate archive lib, libsmartheapC_smp.a (debug libsmartheapC_mtd.a). If you're developing a C++ app you need to link to both libsmartheap_smp.* and libsmartheapC_smp.a. If it's a 'C' app you can omit the C++ archive lib.

5) SmartHeap/SMP 6.02 introduced a new set of "smp-debug" libs (libsmartheap_smpd.* et al). These are *not* intended as replacements for the standard SmartHeap debug libs (libsmartheap_mtd.* et al). See the Getting Started Guide (esp. the section "Using SmartHeap smp-debug libraries") for more info.

If your app crashes when linked to the smp libs and you suspect a heap bug, link with our standard debug libs and see if they detect the problem. If the debug libs don't detect the problem, then try the smp-debug libs.

6) Note that you should not use the SmartHeap/smp libs with a single threaded app. Contact us and we'll send you a single threaded lib to use in your tests.

Re performance testing, we suggest using a benchtest that realistically emulates a real app's alloc pattern and puts more stress on the allocator -- namely, variable-size allocs inspersed randomly with frees of randomly-chosen blocks.