dmalloc.html

减少内存碎片的malloc分配函数

<A NAME="IDX223"></A>
<A NAME="IDX224"></A>
<A NAME="IDX225"></A>

<DT><CODE>23 (ERROR_IS_FOUND)</CODE>
<DD>
This indicates that the pointer specified in the address part of the
environmental variable was discovered by the library.  See section <A HREF="dmalloc.html#SEC29">4.3 Environment Variable Name and Features</A>.  This error is useful so you can put a breakpoint in a
debugger to find where a particular address was allocated.  See section <A HREF="dmalloc.html#SEC18">3.8 Using Dmalloc With a Debugger</A>.

<A NAME="IDX226"></A>
<A NAME="IDX227"></A>
<A NAME="IDX228"></A>
<A NAME="IDX229"></A>
<A NAME="IDX230"></A>

<DT><CODE>24 (ERROR_BAD_FILE)</CODE>
<DD>
A possibly invalid filename was discovered in the dmalloc administrative
sections.  This could indicate some corruption of the internal tables.
It also could mean that you have a source file whose name is longer than
100 characters.  See <CODE>MAX_FILE_LENGTH</CODE> in the <TT>`settings.dist'</TT>
file.

<A NAME="IDX231"></A>
<A NAME="IDX232"></A>
<A NAME="IDX233"></A>
<A NAME="IDX234"></A>
<A NAME="IDX235"></A>

<DT><CODE>25 (ERROR_BAD_LINE)</CODE>
<DD>
A line-number was out-of-bounds in the dmalloc administrative sections.
This could indicate some corruption of the internal tables.  It also
could mean that you have a source file containing more than <CODE>30000</CODE>
lines of code.  See <CODE>MAX_LINE_NUMBER</CODE> in the <TT>`settings.dist'</TT>
file.

<A NAME="IDX236"></A>
<A NAME="IDX237"></A>
<A NAME="IDX238"></A>
<A NAME="IDX239"></A>
<A NAME="IDX240"></A>

<DT><CODE>26 (ERROR_UNDER_FENCE)</CODE>
<DD>
This indicates that a pointer had its lower bound picket-fence magic
number overwritten.  If the <SAMP>`check-fence'</SAMP> token is enabled, the
library writes magic values above and below allocations to protect
against overflow.  Most likely this is because a pointer below it went
past its allocate and wrote into the next pointer's space.

<A NAME="IDX241"></A>
<A NAME="IDX242"></A>
<A NAME="IDX243"></A>
<A NAME="IDX244"></A>
<A NAME="IDX245"></A>

<DT><CODE>27 (ERROR_OVER_FENCE)</CODE>
<DD>
This indicates that a pointer had its upper bound picket-fence magic
space overwritten.  If the <SAMP>`check-fence'</SAMP> token is enabled, the
library writes magic values above and below allocations to protect
against overflow.  Most likely this is because an array or string
allocation wrote past the end of the allocation.

Check for improper usage of <CODE>strcat</CODE>, <CODE>sprintf</CODE>,
<CODE>strcpy</CODE>, and any other functions which work with strings and do
not protect themselves by tracking the size of the string.  These
functions should <EM>always</EM> be replaced with: <CODE>strncat</CODE>,
<CODE>snprintf</CODE>, <CODE>strncpy</CODE>, and others.

<A NAME="IDX246"></A>
<A NAME="IDX247"></A>
<A NAME="IDX248"></A>
<A NAME="IDX249"></A>
<A NAME="IDX250"></A>

<DT><CODE>28 (ERROR_WOULD_OVERWRITE)</CODE>
<DD>
This error is generated by the function pointer checking code usually
enabled wit the <CODE>check-funcs</CODE> token.  Dmalloc overloads a number of
string and memory copying functions and verifies that the buffers (if
allocated in the heap) would not be overwritten by the function.

<A NAME="IDX251"></A>
<A NAME="IDX252"></A>
<A NAME="IDX253"></A>
<A NAME="IDX254"></A>
<A NAME="IDX255"></A>

<DT><CODE>30 (ERROR_NOT_START_BLOCK)</CODE>
<DD>
This indicates that the user passed in a pointer to be freed or
reallocated that was not at the start of the allocation.  You would get
this error, for example, if you allocate and get pointer <CODE>X</CODE> but
then try to free <CODE>X+1</CODE>.

<A NAME="IDX256"></A>
<A NAME="IDX257"></A>
<A NAME="IDX258"></A>
<A NAME="IDX259"></A>
<A NAME="IDX260"></A>

<DT><CODE>40 (ERROR_BAD_SIZE)</CODE>
<DD>
This error indicates that a size value in the internal structures of the
library were corrupted.  This could be a random pointer problem, pointer
overflow, or some other corruption.

<A NAME="IDX261"></A>
<A NAME="IDX262"></A>
<A NAME="IDX263"></A>
<A NAME="IDX264"></A>
<A NAME="IDX265"></A>

<DT><CODE>41 (ERROR_TOO_BIG)</CODE>
<DD>
An allocation asked for memory larger than the configured maximum.  This
is a user configured setting.  See <CODE>LARGEST_ALLOCATION</CODE> in the
<TT>`settings.dist'</TT> file.  It is used to protect against wild
allocation sizes.  If you have super large allocation sizes then you
should tune the <CODE>LARGEST_ALLOCATION</CODE> value appropriately.

<A NAME="IDX266"></A>
<A NAME="IDX267"></A>
<A NAME="IDX268"></A>
<A NAME="IDX269"></A>
<A NAME="IDX270"></A>

<DT><CODE>43 (ERROR_ALLOC_FAILED)</CODE>
<DD>
The library could not allocate more heap space and the program has run
out of memory.  This could indicate that you've overflowed some system
imposed limit.  On many operation systems, the <CODE>ulimit</CODE> call can
tune system defaults.

<A NAME="IDX271"></A>
<A NAME="IDX272"></A>
<A NAME="IDX273"></A>
<A NAME="IDX274"></A>
<A NAME="IDX275"></A>

<DT><CODE>44 (ERROR_ALLOC_NONLINEAR)</CODE>
<DD>
If the <CODE>force-linear</CODE> token is enabled, the library will ensure
that the heap memory returned, is linear and contiguous.  This should
only be used in special circumstances.

<A NAME="IDX276"></A>
<A NAME="IDX277"></A>
<A NAME="IDX278"></A>
<A NAME="IDX279"></A>
<A NAME="IDX280"></A>
<A NAME="IDX281"></A>

<DT><CODE>45 (ERROR_OVER_LIMIT)</CODE>
<DD>
The library has allocated more memory than was specified in the
memory-limit environmental variable.  See section <A HREF="dmalloc.html#SEC29">4.3 Environment Variable Name and Features</A>.

<A NAME="IDX282"></A>
<A NAME="IDX283"></A>
<A NAME="IDX284"></A>
<A NAME="IDX285"></A>
<A NAME="IDX286"></A>

<DT><CODE>60 (ERROR_NOT_ON_BLOCK)</CODE>
<DD>
The user tried to free or realloc a pointer that was not pointing to a
block boundary.  You would get this error, for example, if you allocate
and get pointer <CODE>X</CODE> but then try to free <CODE>X+1</CODE>.

<A NAME="IDX287"></A>
<A NAME="IDX288"></A>
<A NAME="IDX289"></A>
<A NAME="IDX290"></A>
<A NAME="IDX291"></A>

<DT><CODE>61 (ERROR_ALREADY_FREE)</CODE>
<DD>
The user tried to free a pointer than has already been freed.  This is a
very common mistake and can lead to serious problems.  It can be because
a destructor is being called twice for some reason.  Although tracking
down the specific source is highly recommended, it is good to set
pointers to NULL (0L) after you free them as a rule.

<A NAME="IDX292"></A>
<A NAME="IDX293"></A>
<A NAME="IDX294"></A>
<A NAME="IDX295"></A>
<A NAME="IDX296"></A>
<A NAME="IDX297"></A>
<A NAME="IDX298"></A>

<DT><CODE>67 (ERROR_FREE_OVERWRITTEN)</CODE>
<DD>
If either the <CODE>free-blank</CODE> or <CODE>check-blank</CODE> tokens are enabled
then the library will overwrite memory when it is freed with the
"dmalloc-free" byte (hex 0xdf, octal 0337, decimal 223).  If the
program writes into this space, then the library will detect the write
and trigger this error.  This could indicate that the program is using a
pointer after it has been freed.

<A NAME="IDX299"></A>
<A NAME="IDX300"></A>
<A NAME="IDX301"></A>
<A NAME="IDX302"></A>
<A NAME="IDX303"></A>

<DT><CODE>70 (ERROR_ADMIN_LIST)</CODE>
<DD>
An internal corruption in the library's administrative structures has
been detected.  This could be a random pointer problem, pointer
overflow, or some other corruption.

<A NAME="IDX304"></A>
<A NAME="IDX305"></A>
<A NAME="IDX306"></A>
<A NAME="IDX307"></A>
<A NAME="IDX308"></A>

<DT><CODE>72 (ERROR_ADDRESS_LIST)</CODE>
<DD>
An internal corruption in the library's administrative structures has
been detected.  This could be a random pointer problem, pointer
overflow, or some other corruption.

<A NAME="IDX309"></A>
<A NAME="IDX310"></A>
<A NAME="IDX311"></A>
<A NAME="IDX312"></A>
<A NAME="IDX313"></A>

<DT><CODE>73 (ERROR_SLOT_CORRUPT)</CODE>
<DD>
An internal corruption in the library's administrative structures has
been detected.  This could be a random pointer problem, pointer
overflow, or some other corruption.

</DL>



<H2><A NAME="SEC16" HREF="dmalloc.html#TOC16">3.6 How to Disable the library</A></H2>

<P>
<A NAME="IDX314"></A>


<P>
When you are finished with the development and debugging sessions, you
may want to disable the dmalloc library and put in its place either the
system's memory-allocation routines, gnu-malloc, or maybe your own.
Attempts have been made to make this a reasonably painless process.  The
ease of the extraction depends heavily on how many of the library's
features your made use of during your coding.


<P>
Reasonable suggestions are welcome as to how to improve this process
while maintaining the effectiveness of the debugging.



<UL>
<LI>

If you want to <EM>totally</EM> disable the dmalloc library then you will
need to recompile all the C files that include <TT>`dmalloc.h'</TT> while
defining <CODE>DMALLOC_DISABLE</CODE>.  This will cause the dmalloc macros to
not be applied.  See section <A HREF="dmalloc.html#SEC11">3.1 Macros Providing File and Line Information</A>.


<PRE>
cc -g -DDMALLOC_DISABLE main.c
</PRE>

An alternative is to surround the <CODE>dmalloc.h</CODE> inclusion or any
direct dmalloc references with an <CODE>#ifdef DMALLOC</CODE> and then just
remove the -DDMALLOC.


<PRE>
#ifdef DMALLOC
#include "dmalloc.h"
#endif

main()
{
  ...

#ifdef DMALLOC
  dmalloc_verify(0L);
#endif
  return 0;
}
</PRE>


<PRE>
// to get dmalloc information
$ cc -Ddmalloc main.c

// without dmalloc information
$ cc main.c
</PRE>

<LI>

If you compiled any of your source modules with <CODE>DMALLOC_FUNC_CHECK</CODE>
defined then you must first recompile all those modules without the flag
enabled.

If you have disabled dmalloc with the <CODE>DMALLOC_DISABLED</CODE> flag or
never included <TT>`dmalloc.h'</TT> in any of your C files, then you will
not need to recompile your sources when you need to disable the library.

If you get unresolved references like <CODE>_dmalloc_malloc</CODE> or
<CODE>_dmalloc_bcopy</CODE> then something was not disabled as it should have
been.
</UL>



<H2><A NAME="SEC17" HREF="dmalloc.html#TOC17">3.7 Using the Library with C++</A></H2>

<P>
<A NAME="IDX315"></A>
<A NAME="IDX316"></A>


<P>
<A NAME="IDX317"></A>
For those people using the C++ language, the library tries to configure
and build <TT>`libdmallocxx.a'</TT> library.  This library should be linked
into your C++ programs instead of <TT>`libdmalloc.a'</TT>.


<P>
<A NAME="IDX318"></A>
Dmalloc is not as good with C++ as C because the dynamic memory routines
in C++ are <CODE>new()</CODE> and <CODE>delete()</CODE> as opposed to
<CODE>malloc()</CODE> and <CODE>free()</CODE>.  Since new and delete are usually not
used as functions but rather as <CODE>x = new type</CODE>, there is no easy
way for dmalloc to pass in file and line information unfortunately.  The
<TT>`libdmallocxx.a'</TT> library provides the file <TT>`dmallocc.cc'</TT> which
effectively redirects <CODE>new</CODE> to the more familiar <CODE>malloc</CODE> and
<CODE>delete</CODE> to the more familiar <CODE>free</CODE>.


<P>
<EM>NOTE</EM>: The author is not a C++ hacker so feedback in the form of
other hints and ideas for C++ users would be much appreciated.




<H2><A NAME="SEC18" HREF="dmalloc.html#TOC18">3.8 Using Dmalloc With a Debugger</A></H2>

<P>
<A NAME="IDX319"></A>
<A NAME="IDX320"></A>


<P>
Here are a number of possible scenarios for using the dmalloc library to
track down problems with your program.


<P>
You should first enable a logfile filename and turn on a set of debug
features.  You can use <KBD>dmalloc -l logfile low</KBD> to accomplish this.
If you are interested in having the error messages printed to your
terminal as well, enable the <SAMP>`print-messages'</SAMP> token by typing
<KBD>dmalloc -p print-messages</KBD> afterwards.  See section <A HREF="dmalloc.html#SEC26">4. Dmalloc Utility Program</A>.


<P>
<A NAME="IDX321"></A>
<A NAME="IDX322"></A>
Now you can enter your debugger (I use the <EM>excellent</EM> GNU debugger
gdb), and put a break-point in <CODE>dmalloc_error()</CODE> which is the
internal error routine for the library.  When your program is run, it
will stop there if a memory problem is detected.


<P>
If you are using GDB, I would recommend adding the contents of
<TT>`dmalloc.gdb'</TT> in the <TT>`contrib'</TT> subdirectory to your
<TT>`.gdbinit'</TT> file in your home directory.  This enables the
<CODE>dmalloc</CODE> command which will prompt you for the arguments to the
dmalloc command and will set a break point in <CODE>dmalloc_error()</CODE>
automatically.


<P>
<A NAME="IDX323"></A>
<A NAME="IDX324"></A>
If you are using shared libraries, you may want to execute the following
commands initially to load in dmalloc and other library symbols:



<PRE>
(gdb) sharedlibrary
(gdb) add-shared-symbol-files
</PRE>



<H3><A NAME="SEC19" HREF="dmalloc.html#TOC19">3.8.1 Diagnosing General Problems with a Debugger</A></H3>

<P>
<A NAME="IDX325"></A>
<A NAME="IDX326"></A>
<A NAME="IDX327"></A>
<A NAME="IDX328"></A>


<P>
If your program stops at the <CODE>dmalloc_error()</CODE> routine then one
of a number of problems could be happening.  Incorrect arguments could
have been passed to a malloc call: asking for negative number of
bytes, t