107 lines
4.5 KiB
Plaintext
107 lines
4.5 KiB
Plaintext
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 addres 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. You are using a non-Win32 platform, and most likely using
|
|
gcc or egcs, and is probably running with the highest
|
|
possible warning levels. This is a Good Thing.
|
|
|
|
Unfortunately, it seems some compilers get a bit too
|
|
paranoid at those levels. There is nothing wrong with
|
|
memwatch's code. Nothing that matters will get
|
|
clobbered, if the compiler adheres to the ANSI C
|
|
standard. Just ignore the warnings.
|