Node:Debugging, Next:Profiling, Previous:Efficiency, Up:GMP Basics
--enable-alloca choices in
Build Options, for how to address this.
init GMP variables will have unpredictable effects, and
corruption arising elsewhere in a program may well affect GMP. Initializing
GMP variables more than once or failing to clear them will cause memory leaks.
In all such cases a malloc debugger is recommended. On a GNU or BSD system
the standard C library malloc has some diagnostic facilities, see
Allocation Debugging, or
man 3 malloc. Other possibilities, in no particular order, include
http://www.inf.ethz.ch/personal/biere/projects/ccmalloc http://quorum.tamu.edu/jon/gnu (debauch) http://dmalloc.com http://www.perens.com/FreeSoftware (electric fence) http://packages.debian.org/fda http://www.gnupdate.org/components/leakbug http://people.redhat.com/~otaylor/memprof http://www.cbmamiga.demon.co.uk/mpatrol
The GMP default allocation routines in memory.c also have a simple
sentinel scheme which can be enabled with #define DEBUG in that file.
This is mainly designed for detecting buffer overruns during GMP development,
but might find other uses.
-fomit-frame-pointer
is used and this generally inhibits stack backtracing. Recompiling without
such options may help while debugging, though the usual caveats about it
potentially moving a memory problem or hiding a compiler bug will apply.
.gdbinit is included in the distribution, showing how to call
some undocumented dump functions to print GMP variables from within GDB. Note
that these functions shouldn't be used in final application code since they're
undocumented and may be subject to incompatible changes in future versions of
GMP.
mpz, mpq, mpf and mpfr each have an
init.c. If the debugger can't already determine the right one it may
help to build with absolute paths on each C file. One way to do that is to
use a separate object directory with an absolute path to the source directory.
cd /my/build/dir /my/source/dir/gmp-4.1/configure
This works via VPATH, and might require GNU make.
Alternately it might be possible to change the .c.lo rules
appropriately.
--enable-assert is available to add some consistency
checks to the library (see Build Options). These are likely to be of
limited value to most applications. Assertion failures are just as likely to
indicate memory corruption as a library or compiler bug.
Applications using the low-level mpn functions, however, will benefit
from --enable-assert since it adds checks on the parameters of most
such functions, many of which have subtle restrictions on their usage. Note
however that only the generic C code has checks, not the assembler code, so
CPU none should be used for maximum checking.
--enable-alloca=debug arranges that each block of
temporary memory in GMP is allocated with a separate call to malloc (or
the allocation function set with mp_set_memory_functions).
This can help a malloc debugger detect accesses outside the intended bounds,
or detect memory not released. In a normal build, on the other hand,
temporary memory is allocated in blocks which GMP divides up for its own use,
or may be allocated with a compiler builtin alloca which will go
nowhere near any malloc debugger hooks.
A build of GMP with checking within GMP itself can be made. This will run
very very slowly. Configure with
./configure --host=none-pc-linux-gnu CC=checkergcc
--host=none must be used, since the GMP assembler code doesn't support
the checking scheme. The GMP C++ features cannot be used, since current
versions of checker (0.9.9.1) don't yet support the standard C++ library.
Current versions (20020226 snapshot) don't support MMX or SSE, so GMP must be
configured for an x86 without those (eg. plain i386), or with a special
MPN_PATH that excludes those subdirectories (see Build Options).