I.1 Notes for all platforms
- Overriding the C++ operators to get source-level information using the
preprocessor is still a bit dodgy and isn't likely to get much better, so
MP_NONEWDELETE may have to be used a lot. Explicit references to
operator new rather than
new are likely to result in compilation
errors, and the way that source level information is obtained for
operator delete means that the resulting code will not be thread-safe.
It might also be an idea to provide an allocation class from which user-defined
memory allocators can be derived.
- Need to add support for other 64-bit processors in addition to the existing
Alpha and SPARC V9 support. This shouldn't be too hard, but I haven't got
access to such processors to test them, so I haven't been able to yet. Also
need to add support for building on targets and architectures where no operating
system features are required or even available.
- Need to improve the concurrency in the thread-safe version of the mpatrol
library. Currently, only one thread at a time is allowed to enter the mpatrol
library, but it should be possible to extend this to protect individual data
structures. Note that this will not only help to improve efficiency, but might
also allow the mpatrol library to uncover bugs in thread-safe code that are
- Need to make the library re-entrant. This could be achieved by moving the
static variables in memory.c, stack.c, mutex.c,
diag.c, trace.c, option.c and sbrk.c into the
infohead structure and then having an array of
from which to allocate new memory headers when a new one is required. This is
only necessary for Amiga shared libraries and Netware NLMs since UNIX and
Windows platforms allocate a new copy of the data section in a shared library or
DLL when it is opened by a new process.
- Some implementations of call stack traversal are limited and will only likely
work for unoptimised code. A much better solution would be write the
implementations at a lower level in assembly, but this is much less portable.
Perhaps there is a library which can be used to perform this across many
operating systems and processor architectures, or maybe someone would like to
write one1? I can think of many applications that would benefit from such a
library besides this one.
- An alternative implementation for call stack traversal uses the functions
__builtin_return_address() that are
available when the library is compiled with gcc. However, they can
only traverse a number of stack frames at compile-time, not run-time so there is
a maximum number of stack frames that can be traversed at any one time. The
implementation depends on both of these builtin functions returning `NULL'
when the top of stack is reached. If this is not the case then this method
cannot be used or should only be used with a small number of fixed stack frames.
backtrace() from glibc is also supported as well.
- Is it worth adding functions to manually push and pop entries on the call stack
for platforms which have no support for call stack traversal? This is currently
not a high-priority issue since almost all of the platforms that mpatrol is
available on have support for full call stack traversal. However, it might be
handy anyway as an additional debugging tool for entering and leaving scopes.
- Need to change
__mp_compareaddrs() so that it will improve the detection
of when to free memory allocations made by
alloca() and its related
functions. This will involve checking the common return addresses in the call
stacks instead of just checking them if the stack depth is the same. Also,
on systems that don't have full call stack traversal, the minimum number of
bytes that stack frames should differ by should be platform-dependent since the
current value is way too high.
- Perhaps hash the call stacks when they are stored internally by the routines in
addr.c. This would make for quick checks to see if two call stacks are
identical and it might save some memory in the process.
- There is an issue with callback functions if they call mpatrol library
functions, since this may lead to recursion in some obscure cases. Callback
functions could also be defined for
__free_hook() in much the same way as for the
GNU C library.
- Need to store filename and line number information in all call stacks so that
the information can be used at program termination. May also need to display
this information in the
__mp_printinfo() function and add this
information to the profiling output file so that mprof can make use of
- In object file formats that support nested symbols (such as ELF), the current
implementation will tend to show some shortcomings. This is because there is
currently no nesting count in the function that deals with symbol name lookup,
so the wrong symbol name may be displayed in diagnostics.
- In object file formats that don't store the sizes of symbols (such as basic
a.out, or when using the GNU BFD library), the current implementation
will simply assume that the current symbol terminates at the beginning of the
next symbol in the virtual address space.
- Perhaps add an option to prevent symbols from being read from object files.
This might be necessary if mpatrol is used in a program that loads shared
libraries explicitly, or if there is too much memory being used by mpatrol to
store the symbol details.
- Add functions to start and stop profiling, and perhaps also to clear the
profiling tables and begin a new profiling output file. Should also write more
information to the profiling output file, such as the date that it was produced
on and the word size of the processor that it was produced on, so that
mprof will not crash when reading a profiling output file produced on
a processor that has a different word size.
- Perhaps add the ability to profile memory operations such as
memset() to the existing memory allocation profiling facility. Also, add
options to mprof to write out files that can be used by chart drawing
software for a better visualisation of the first few profiling tables.
- Perhaps the allocation call graph table should have the capability to be sorted
in mprof and the --leaks option should work with it as well.
There should be better handling of cycles in the call graph and there is
currently a problem in that mprof cannot distinguish between call
sites with very low code addresses that have no symbols and that conflict with
existing symbol indices.
- Extend the mptrace command to graphically display the size of the heap
plotted against time and the allocation size frequency. Also rewrite the GUI
support to use GNOME instead of Motif, possibly also using GLADE.
- Possibly add widgets to the mptrace window to pause and quit. Might
also be handy to add the ability to write out charts summarising tracing
- Handle marked memory allocations in the leak table, and also perhaps write out
to the mpatrol log file when an allocation is marked so that the mleak
command will work correctly.
- Improve the speed of watch points by setting a range of allocation indices for
which they will be used. This may require a lot of code changes in
- Add a software watch point facility that can be placed on ranges of addresses in
the heap. Then, if a heap operation touches the watch point, either the user
can be notified or a callback function can be called. The same could be done
for local variables if the stack frame can be easily determined, which would
also allow detecting if a read from or write to memory was performed just beyond
the stack pointer.
- Add a CRC checksum to memory blocks and use it to check that freed memory
allocations have not been corrupted when the NOFREE and
PRESERVE options are in use on platforms which have no memory
- Perhaps extend the NOFREE option to prevent the mpatrol library from
reusing freed memory allocations unless it really needs to. This would mean
that no freed allocations would be reused until there is no more free memory
left and mpatrol would normally have to allocate more from the system. It could
then convert as many freed allocations to free memory as it needs to fulfil the
allocation request, although it would probably still have to abide by the
minimum number of freed allocations set by the NOFREE option.
- Perhaps change the behaviour of the NOFREE option so that it doesn't
prevent in-place reallocations if there is enough memory to perform them. Then
an option could be added to force reallocations to always allocate new memory
so that the behaviour could also be used when the NOFREE option is not
- Add an option to set up a timer that will automatically check the heap after a
certain number of clock cycles have elapsed. This could be useful in programs
that have long periods of time where no dynamic memory allocation functions are
called, but heap allocations are still manipulated. In addition, checks could
automatically be made upon receipt of special signals sent to the program by
the user and information about the last successful verification of the heap
could be used to narrow down problems. Perhaps even some statistics could be
printed on receipt of a special signal as well.
- Add a diagnostic number count to each warning and error reported in the log
file. This could then be used to implement a DIAGSTOP option which
would stop the program running after a certain number of diagnostics have been
- Add the ability to stop in a debugger when a memory allocation is made from a
particular file and line number, and perhaps also trap when a particular address
is allocated as part of a memory allocation.
- Perhaps add time information to the details stored about each memory allocation.
This is probably not useful unless the system provides a high-resolution timer.
- Add an option (perhaps NOINTERNAL) to suppress the display of internal
(recursive) memory allocations in the mpatrol log file and also prevent
information about such allocations being written to the profiling output and
tracing output files. Perhaps this could be made the default so that they
behave in the same way as marked allocations, in which case we might want an
option which prevents internal and marked allocations being hidden. This could
also be extended to prevent memory leaks from being reported if the original
allocations were made from a given set of functions.
- Add a function to add a block of memory to the heap, possibly a memory-mapped
file. Also add a function that can shrink the heap if large areas of free
- Maybe show the contents of the MPATROL_OPTIONS environment variable in the
summary as well.
- Add versions of
msize() which are provided
in many other malloc libraries. These won't necessarily behave in exactly the
same way as existing implementations, but at least there won't be link errors
when compiling source code which uses them. Also, add support for setting as
many remaining options in
__mp_setoption() as possible and perhaps even
some options before the mpatrol library has been initialised.
- Add similar functions to the GNU
Perhaps also add an mpatrol tool to add compatibility with the GNU memusage
- Perhaps add debugging/tracing versions of the string manipulation functions,
strcmp() in much the same way as was done for
the memory operation functions. The only problem with this would be locale
support, but perhaps it might be easier just to assume the C locale to begin
with. Also need to have better detection of internal and free blocks when
displaying memory range errors.
- Add wide-character equivalents of
memset(), etc. These are defined as
wmemset(), etc. and are now part of ANSI C. Also add
xmemdup() as well as
- Perhaps reimplement the standard I/O library for internal use by mpatrol, thus
preventing recursive calls to
malloc() each time a write to the log file
occurs on some systems. Example code to do this was submitted by Alexander
Barton and this may well be incorporated into the library at some point in the
- Add the ability to use the reporting and tracing infrastructure of mpatrol
with the existing C library's memory allocation implementation.
- The LOG* options could be extended to take a list of specific functions
to log. They could also only log operations spanning a range of addresses or
allocation indices as well.
- Add an option to limit the size of each memory allocation to a maximum number
of bytes. This could be useful if a memory allocation function is called with
an uninitialised variable.
- Add assertion macros to mpatrol.h that can be used in program code.
These could be used to assert that pointers have not been freed, are valid
heap addresses or are strings, or perhaps even that the address is readable,
writable and/or executable. They would be disabled if
NDEBUG is defined.
- Add support functions that could be added to user code to enter and leave
scopes in a source file and ensure that all allocations allocated within the
scope are freed by the time the scope has been exited.
- Add support for the -finstrument-functions option of the GNU compiler.
This would allow mpatrol to keep track of the entry to and exit from every
function, but would only work for code compiled with this option.
- Extend the Checker-support functions to store and check information about
access permissions within heap memory and perhaps also in the stack as well,
and also improve the diagnostics from the checker functions if they fail.
Currently, the Checker-support functions only ensure that no memory accesses
cross allocation boundaries or access free memory. Could also make use of the
end pointers that are set at run-time on
most UNIX systems. Need to properly implement
- Details of the segments which make up the executable file and any shared
libraries could be made use of in order to detect operations which cross such
segments. For example, a memory operation may erroneously cross the data
and BSS segments. The symbol table for data symbols could also be used to
provide much finer-grained error-checking. Need to make use of the
- Add garbage detection support to mpatrol. This would be implemented as a
function that would traverse all of the roots of the memory in a process and
look for pointers into free memory or the lack of any pointers into allocated
memory (to detect memory leaks).
- Add an option to specify that all failed memory allocations should abort (or at
least give a warning) instead of returning a `NULL' pointer. Also, perhaps
add an option to display the partial contents of freed and unfreed allocations
in the mpatrol log file.
- Perhaps add memory protection to the simulated
- Add an option to force the mpatrol library to return `NULL' if it is
asked to allocate a zero-sized block of memory. This might be useful for SVID
compliant programs. Perhaps also extend the mpatrol library to allow
zero-sized blocks. I suspect the easiest way to do this is to have a special
address that is always returned for such blocks and that will have the
appropriate size of overflow buffers depending on the options used.
- Add an option to report if one thread resizes or frees another thread's
allocations. This may not be useful in most cases, but it might be possible
to track down some obscure bugs in some situations.
- Perhaps add internationalisation support through the use of locales and message
catalogs. Unfortunately, there does not appear to be a unified method for doing
this across all platforms and there may also be issues with third-party
malloc() and other related routines when the mpatrol
library is attempting to initialise itself.
- There is currently a problem when the mpatrol library encounters an illegal
memory access on UNIX and Windows platforms, and there is a further illegal
memory access when it is displaying the summary. This should be prevented by
disabling the signal handler at its first entry.
- Need to make the mpalloc library threadsafe3. This is only likely to be an issue when
MP_FAILURE(). Should also add something similar to
xmalloc_set_program_name() in order to show the program name when a
memory allocation fails. If the C++ operators fail to allocate memory in
libmpalloc then there should probably also be an exception thrown to mimic the
behaviour of libmpatrol, although this isn't a big issue since the program
should be completely recompiled to remove mpatrol debugging before a release.
In the same vein, perhaps there should be some sort of support for
set_new_handler() in libmpalloc.
- Add an option to write the mpatrol log file in HTML format, or even better XML
format. Need to also extend what is written out by the --hatf-file
- The mpsym command could optionally preserve any stack traceback lines
that already have symbolic or debugging information associated with them. It
could also support more debuggers other than just gdb. Finally, it
could support - as the filename for reading the mpatrol log file from the
standard input file stream.
- A good idea might be to have the mpatrol command read options from a
configuration file instead of an environment variable, but that will only work
if it doesn't involve allocating any memory before the mpatrol library has been
- Perhaps incorporate a C++ encoded name demangler into the mpatrol library. The
most likely candidate is the GNU demangler that comes with the libiberty
library, but that currently allocates temporary space on the heap using
xmalloc() which means that it will run unbearably slowly under
- Add a script to wrap around various popular C and C++ compiler drivers so that
linking with the mpatrol library is much less laborious. In addition, a
user-defined command or script file could be executed at the end of every
invocation of the mpatrol command.
- Add a script to automatically run the mpatrol library tests. It could be quite
hard to verify the tests since the heap addresses are likely to be different on
every new build and will certainly be different across different platforms.
- Improve the autoconf, automake and libtool support. Also update the
mupdate shell script to automatically update the version numbers
contained in the files in the pkg directory.
- The postscript version of the quick reference card seems to print at an unusual
offset on some printers.
- Perhaps add benchmark tests for dynamic memory allocation functions and memory
operation functions. Obviously the mpatrol library would perform much worse
than normal malloc libraries, but it would help to see just how much worse so
that speed improvements could be made.
- Add support for the BeOS operating system, as well as MacOS, NeXT and OS/2.
Perhaps MS-DOS might be possible as well.