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.
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. If your EXE is *not* linked to SmartHeap and you're
using SmartHeap with 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
3) We recommend using the Sun Workshop 5 and 6 ('Forte') compilers: these
are the compilers we support. 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 workshop) compilers.
Also follow the supported compiler instructions if you're using Sun Workshop
4.2. it's fairly common for this compiler to complain about SmartHeap's
C++ declarations (in smrtheap.hpp). There are workarounds for these problems:
contact microquill tech support (email@example.com) for details.
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