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 timing-dependent.

• 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 infohead structures 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 one(57)? I can think of many applications that would benefit from such a library besides this one(58).

• An alternative implementation for call stack traversal uses the functions __builtin_frame_address() and __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. However, perhaps there might even be a use for an option to limit the number of stack frames in stack tracebacks for systems that have no such limitation.

• 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 __malloc_hook(), __realloc_hook() and __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 it.

• 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 memcpy() and 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 information.

• 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 `alloc.c'.

• 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 protection.

• 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 used.

• 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 displayed.

• 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 memory exist.

• Maybe show the contents of the MPATROL_OPTIONS environment variable in the summary as well.

• Add versions of mallopt(), mallinfo(), memorymap(), mallocctl(), mallocblksize() and 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 mcheck() and mprobe() functions. Perhaps also add an mpatrol tool to add compatibility with the GNU memusage tool.

• Perhaps add debugging/tracing versions of the string manipulation functions, such as strlen() and 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 wcsdup(), memdup() and xmemdup() as well as mempcpy() and memrchr().

• 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 (abarton@innotrac.com) and this may well be incorporated into the library at some point in the future(59).

• 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 etext, edata and end pointers that are set at run-time on most UNIX systems. Need to properly implement chkr_check_exec().

• 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 __mp_memquery() function.

• 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 sbrk heap.

• 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 libraries calling 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 threadsafe(60). This is only likely to be an issue when calling 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' option.

• 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 initialised.

• 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 mpatrol(61).

• 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. In addition, the mpatrol manual should also be formatted in DocBook format once a suitable TeXinfo to DocBook translator is available.

• 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.