faq

最近在UNIX下开发代码

Frequently Asked Questions for memwatch

Q. I'm not getting any log file! What's wrong??

A. Did you define MEMWATCH when compiling all files?
   Did you include memwatch.h in all the files?
   If you did, then...:

   Memwatch creates the file when it initializes. If you're not
   getting the log file, it's because a) memwatch is not
   initializing or b) it's initializing, but can't create the
   file.
   
   Memwatch has two functions, mwInit() and mwTerm(), that
   initialize and terminate memwatch, respectively. They are
   nestable. You USUALLY don't need to call mwInit() and
   mwTerm(), since memwatch will auto-initialize on the first
   call to a memory function, and then add mwTerm() to the
   atexit() list.
   
   You can call mwInit() and mwTerm() manually, if it's not
   initializing properly or if your system doesn't support
   atexit(). Call mwInit() as soon as you can, and mwTerm() at
   the logical no-error ending of your program. Call mwAbort()
   if the program is stopping due to an error; this will
   terminate memwatch even if more than one call to mwTerm() is
   outstanding.
   
   If you are using C++, remember that global and static C++
   objects constructors execute before main() when considering
   where to put mwInit(). Also, their destructors execute after
   main(). You may want to create a global object very early
   with mwInit() in the constructor and mwTerm() in the
   destructor. Too bad C++ does not guarantee initialization
   order for global objects.
   
   If this didn't help, try adding a call to mwDoFlush(1) after
   mwInit(). If THAT didn't help, then memwatch is unable to
   create the log file. Check write permissions.
   
   If you can't use a log file, you can still use memwatch by
   redirecting the output to a function of your choice. See the
   next question.

Q. I'd like memwatch's output to pipe to my fave debugger! How?

A. Call mwSetOutFunc() with the address of a "void func(int c)"
   function. You should also consider doing something about
   the ARI handler, see memwatch.h for more details about that.

Q. Why isn't there any C++ support?

A. Because C++ is for sissies! =) Just kidding.
   C++ comes with overridable allocation/deallocation
   built-in. You can define your own new/delete operators
   for any class, and thus circumvent memwatch, or confuse
   it to no end. Also, the keywords "new" and "delete" may
   appear in declarations in C++, making the preprocessor
   replacement approach shaky. You can do it, but it's not
   very stable.
   
   If someone were to write a rock solid new/delete checker
   for C++, there is no conflict with memwatch; use them both.

Q. I'm getting "WILD free" errors, but the code is bug-free!

A. If memwatch's free() recieves a pointer that wasn't allocated
   by memwatch, a "WILD free" message appears. If the source of
   the memory buffer is outside of memwatch (a non-standard
   library function, for instance), you can use mwFree_() to
   release it. mwFree_() calls free() on the pointer given if
   memwatch can't recognize it, instead of blocking it.
   
   Another source of "WILD free" messages is that if memwatch
   is terminated before all memory allocated is freed, memwatch
   will have forgotten about it, and thus generate the errors.
   This is commonly caused by having memwatch auto-initialize,
   and then using atexit() to clean up. When auto-initializing,
   memwatch registers mwTerm() with atexit(), but if mwTerm()
   runs before all memory is freed, then you will get "unfreed"
   and "WILD free" messages when your own atexit()-registered
   cleanup code runs, and frees the memory.

Q. I'm getting "unfreed" errors, but the code is bug-free!

A. You can get erroneous "unfreed" messages if memwatch 
   terminates before all memory has been freed. Try using
   mwInit() and mwTerm() instead of auto-initialization.
   
   If you _are_ using mwInit() and mwTerm(), it may be that
   some code in your program executes before mwInit() or
   after mwTerm(). Make sure that mwInit() is the first thing
   executed, and mwTerm() the last.

Q. When compiling memwatch I get these 'might get clobbered'
   errors, and something about a longjmp() inside memwatch.

A. When using gcc or egcs with the optimization to inline
   functions, this warning occurs. This is because gcc and
   egcs inlines memwatch's functions with setjmp/longjmp,
   causing the calling functions to become unstable.
   
   The gcc/egcs maintainers have been informed of this
   problem, but until they modify the inline optimization
   so that it leaves setjmp functions alone, make sure to 
   compile memwatch without inline function optimizations.
   
   gcc 2.95.2 can be patched for this, and I have been told
   it will be fixed in an upcoming version.

Q. My program crashes with SIGSEGV or alignment errors, but
   only when I compile with memwatch enabled!

A. You are using a 64-bit (or higher) platform, and memwatch
   was unable to detect and adjust for this. You'll have to
   either compile with a suitable define for mwROUNDALLOC,
   I suggest (number of bits / 8), or define mwROUNDALLOC 
   directly in memwatch.c.
   
   Also, please check your limits.h file for the relevant
   #defines, and tell me what they are.

Q. When I include string.h after memwatch.h, I get errors
   related to strdup(), what gives?

A. Most, but probably not all, platforms are nice about
   including files multiple times, so I could probably
   avoid these errors by including string.h from memwatch.h.
   But since I want to be on the safe side, I don't.
   
   To fix this, simply include string.h before memwatch.h, 
   or modify memwatch.h to include string.h.