加入 Gitee
与超过 1200万 开发者一起发现、参与优秀开源项目,私有仓库也完全免费 :)
免费加入
文件
该仓库未声明开源许可证文件(LICENSE),使用请关注具体项目描述及其代码上游依赖。
克隆/下载
FAQ 5.57 KB
一键复制 编辑 原始数据 按行查看 历史
viruscamp 提交于 2014-10-18 21:53 . memwatch 2.71
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.
马建仓 AI 助手
尝试更多
代码解读
代码找茬
代码优化