国产高潮久久免费观看,精品久久人妻av中文字幕,色综合久久久久

Memwatch Tool

T.S Liu — Tue, 01 Jul 2008 02:12:00 GMT

1 介绍
MemWatch�?Johan Lindh �~�写�Q�是一个开放源代码 C 语言内存错误��工兗��MemWatch支持 ANSI C�Q�它提供�l�果日志�U�录�Q�能��双重释放（double-free�Q�、错误释放（erroneous free�Q�、内存泄漏（unfreed memory�Q�、溢�?Overflow)、下�?Underflow)�{�等�?/p>

1.1 MemWatch的内存处�?br> MemWatch��所有分配的内存�?xFE填充�Q�所以，如果你看到错误的数据是用0xFE填充的，那就是你没有初始化数据。例外是calloc()�Q�它会直接把分配的内存用0填充�?/p>

MemWatch��所有已释放的内存用0xFD填充(zapped with 0xFD).如果你发��C��使用的数据是�?xFD填充的，那你��׃��用的是已释放的内存。在�q�种情况�Q�注意MemWatch会立��x��一�?释放了的块信�?填在释放了的数据前。这个块包括关于内存在哪儉K��攄��信息�Q�以可读的文本�Ş式存放，格式�?FBIfilename(line)"。如:"FBI<267>test.c(12)".使用FBI会降低free()的速度�Q�所以默认是关闭的。��用mwFreeBufferInfo(1)开启�?

��Z��帮助跟踪野指针的写情况，MemWatch能提供no-mans-land�Q�NML�Q�内存填充。no-mans-land��?xFC填充.当no-mans-land开启时�Q�MemWatch转变释放的内存�ؓNML填充状态�?/p>

1.2初始化和�l�束处理
一般来��_��在程序中使用MemWatch的功能，需要手动添加mwInit()�q�行初始化，�q�用对应的mwTerm ()�q�行�l�束处理�?/p>

当然�Q�如果没有手动调用mwInit()�Q�MemWatch能自动初始化.如果是这�U�情形，memwatch会��用atext()注册mwTerm()用于atexit-queue. 对于使用自动初始�?a onclick="javascript:tagshow(event, '%BC%BC%CA%F5');" href="javascript:;" target=_self>技�?/font>有一个告�?如果你手动调用atexit()以进行清�?a onclick="javascript:tagshow(event, '%B9%A4%D7%F7');" href="javascript:;" target=_self>工作�Q�memwatch可能在你的程序结束前��q��止。�ؓ了安全�v见，��h��式��用mwInit()和mwTerm().

涉及的函��C��要有�Q?/p>

mwInit() mwTerm() mwAbort()

1.3 MemWatch的I/O 操作
对于一般的操作�Q�MemWatch创徏memwatch.log文�g。有�Ӟ��该文件不能被创徏;MemWatch会试囑ֈ�建memwatNN.log文�g�Q�NN�?1~99之间�?/p>

如果你不能��用日志，或者不想��用，也没有问题。只要��用类型�ؓ"void func(int c)"的参数调用mwSetOutFunc()�Q�然后所有的输出都会按字节定向到该函�?

当ASSERT或者VERIFY��p�|�Ӟ��MemWatch也有Abort/Retry/Ignore处理机制。默认的处理机制没有I/O操作�Q�但是会自动中断�E�序。你可以使用��M��其他Abort/Retry/Ignore的处理机�?只要以参�?void func(int c)"调用mwSetAriFunc()。后面在1.2使用一节会详细讲解�?/p>

涉及的函��C��要有�Q?/p>

mwTrace() mwPuts() mwSetOutFunc() mwSetAriFunc()

mwSetAriAction() mwAriHandler() mwBreakOut()

1.4 MemWatch对C++的支�?br> 可以��MemWatch用于C++,但是不推荐这么做。请详细阅读memwatch.h中关于对C++的支持�?/p>

2 使用
2.1 ��q��E�序提供MemWatch功能
在要使用MemWatch�?c文�g中包含头文�g"memwatch.h"

使用GCC�~�译�Q�注意：不是链接�Q�自��q��E�序�Ӟ��加入-DMEMWATCH -DMW_STDIO
如：gcc -DMEMWATCH -DMW_STDIO –o test.o –c test1.c

2.2 使用MemWatch提供的功�?br>1�Q�在�E�序中常用的MemWatch功能有：

mwTRACE ( const char* format_string, ... );
或TRACE ( const char* format_string, ... );

mwASSERT ( int, const char*, const char*, int )
或ASSERT ( int, const char*, const char*, int )

mwVERIFY ( int, const char*, const char*, int )
或VERIFY ( int, const char*, const char*, int )

mwPuts ( const char* text )

ARI机制�Q?mwSetAriFunc(int (*func)(const char *))�Q?br> mwSetAriAction(int action)�Q?br> mwAriHandler ( const char* cause )�Q?/p>

mwSetOutFunc (void (*func)(int))

mwIsReadAddr(const void *p, unsigned len )

mwIsSafeAddr(void *p, unsigned len )

mwStatistics ( int level )

mwBreakOut ( const char* cause)

2�Q�mwTRACE�Q�mwASSERT�Q�mwVERIFY和mwPuts��֐�思义�Q�就不再赘述。仅需要注意的是，Memwatch定义了宏TRACE, ASSERT �?VERIFY.如果你已使用同名的宏,memwatch2.61及更高版本的memwatch不会覆盖你的定义。MemWatch2.61及以后，定义了mwTRACE, mwASSERT �?mwVERIFY宏，�q�样�Q�你��p��定使用的是memwatch的宏定义�?.61版本前的memwatch会覆盖已存在的同名的TRACE, ASSERT �?VERIFY定义�?/p>

当然�Q�如果你不想使用MemWatch的这几个宏定义，可以定义MW_NOTRACE, MW_NOASSERT �?MW_NOVERIFY宏，�q�样MemWatch的宏定义��׃��起作用了。所有版本的memwatch都遵照这个规则�?/p>

3�Q�ARI机制即程序设�|�的“Abort, Retry, Ignore选择陷阱�?/p>

mwSetAriFunc�Q?/p>

讄��“Abort, Retry, Ignore”发生时的MemWatch调用的函�?当这栯��|�调用的函数地址�Ӟ��实际的错误消息不会打印出来，但会作�ؓ一个参数进行传递�?/p>

如果参数传递NULL�Q�ARI处理函数会被再次关闭。当ARI处理函数关闭后， meewatch会自动调用有mwSetAriAction()指定的操作�?/p>

正常情况下，��p�|的ASSERT() or VERIFY()会中断你的程序。但�q�可以通过mwSetAriFunc()改变�Q�即通过��函�?int myAriFunc(const char *)"传给它实现。你的程序必��询问用��h��否中断，重试或者忽略这个陷阱。返�?用于Abort�Q?1用于Retry�Q�或�?对于Ignore。注意retry�Ӟ��会导致表辑ּ�重新求�?

MemWatch有个默认的ARI处理器。默认是关闭的，但你能通过调用mwDefaultAri()开启。注意这仍然会中止你的程序除非你定义MEMWATCH_STDIO允许MemWatch使用标准C的I/O��?/p>

同时�Q�设�|�ARI函数也会��D��MemWatch不将ARI的错误信息写向标准错误输出，错误字符串而是作�ؓ'const char *'参数传递到ARI函数.

mwSetAriAction�Q?/p>

如果没有ARI处理器被指定�Q�设�|�默认的ARI�q�回倹{��默认是MW_ARI_ABORT

mwAriHandler�Q?/p>

�q�是个标准的ARI处理器，如果你喜�Ƣ就��管用。它��错误输出到标准错误输出�Q��ƈ从标准输入获得输入�?/p>

mwSetOutFunc�Q?/p>

��输��{向调用者给出的函数(参数卛_��数地址)。参��CؓNULL�Q�表�C�把输出写入日志文�gmemwatch.log.

mwIsReadAddr:

��查内存是否有��d��的权�?/p>

mwIsSafeAddr:

��查内存是否有诅R��写的权�?/p>

mwStatistics:

讄��状态搜集器的行为。对应的参数采用宏定义�?/p>

#define MW_STAT_GLOBAL 0 /* 仅搜集全局状态信�?*/

#define MW_STAT_MODULE 1 /* 搜集模块�U�的状态信�?*/

#define MW_STAT_LINE 2 /* 搜集代码行��的状态信�?*/

#define MW_STAT_DEFAULT 0 /* 默认状态设�|?*/

mwBreakOut:

当某些情况MemWatch觉得中断(break into)�~�译器更好时�Q�就调用�q�个函数.如果你喜�Ƣ��用MemWatch,那么可以在这个函��C��讄��执行断点�?/p>

其他功能的��用，请参考源代码的说明�?/p>

2.3分析日志文�g
日志文�gmemwatch.log中包含的信息主要有以下几点：

��试日期

状态搜集器的信�?/p>

使用MemWatch的输出函数或宏（如TRACE�{�）的信息�?/p>

MemWatch捕获的错误信�?/p>

内存使用的全局信息�l�计�Q�包括四点：1�Q�分配了多少�ơ内�?2�Q�最大内存��用量3�Q�分配的内存总量 4�Q��ؓ释放的内存��L��

MemWatch捕获的错误记录在日志文�g中的输出格式如下�Q?/p>

message: filename(linenumber), information

2.4 注意事项
mwInit()和mwTerm()是对应的.所以��用了多少�ơmwInit()�Q�就需要调用多��次

mwTerm()用于�l�止MemWatch.

如果在流�E�中捕获了程序的异常中断�Q�那么需要调用mwAbort()而不�?/p>

mwTerm()。即使有昄��的调用mwTerm()�Q�mwAbort()也将�l�止MemWatch�?/p>

MemWatch不能��保是线�E�安全的。如果你��y使用Wind32或者你使用了线�E�，作�ؓ2.66�Q�是初步支持�U�程的。定义WIN32或者MW_PTHREADS以明��支持线�E�。这会导致一个全局互斥变量产生�Q�同时当讉K��全局内存链时�Q�MemWatch会锁定互斥变量，但这�q�不能证明是�U�程安全的�?/p>

3 �l�论
从MemWatch的��用可以得知，无法用于内核模块。因为MemWatch自��n��׃��用了应用层的接口�Q�而不是内核接口。但是，对于普通的应用层程序，我认��是比较有用，�q�且是开源的�Q�可以自�׃��改代码实玎ͼ�它能方便地查扑ֆ�存泄漏，特别是提供的接口函数��单易懂，学习掌握很容易，对应用层�E�序�?a onclick="javascript:tagshow(event, '%B5%A5%D4%AA%B2%E2%CA%D4');" href="javascript:;" target=_self>单元��试会较适用�?/p>

T.S Liu 2008-07-01 10:12 发表评论

Linux 内存调试工具- Valgrind 使用初探

T.S Liu — Tue, 01 Jul 2008 02:02:00 GMT

Valgrind 是在linux�pȝ��下开发应用程序时用于调试内存问题的工兗��它��其擅长发现内存��理的问题，它可以检查程序运行时的内存泄漏问题�?/span>

它的官方�|�址�?http://www.valgrind.org/

下蝲最新版本的Valgrind�Q�目前是3.2.0�?wget http://www.valgrind.org/downloads/valkyrie-1.2.0.tar.bz2

执行常规的安装步骤：./confgure && make && make install。注意： �pȝ��必须安装QT的开发包。即便这样在make 时还是出现qplatformdefs.h�q�个文�g找不到的情况�Q�导致make��p�|。查扄��l�中的qplatformdefs.h 之后�Q�发现没有存在于qt的标准头文�g目录/usr/lib/qt-3.3/include。如是将/usr/lib/qt-3.3/mkspecs/linux-g++/ 目录下该头文件复制标准头文�g目录�Q�重新make �Q�后面一切OK�?/p>

初次使用

    �~�译如下代码:  gcc -Wall example.c -g -o example

#include 
            void f(void)
            {
            int* x = malloc(10 * sizeof(int));
            x[10] = 0;        // problem 1: heap block overrun
            }                    // problem 2: memory leak -- x not freed
            int main(void)
            {
            f();
            return 0;
            }

注意�Q�gcc �?g 选项让Valgrind调试输出时指出相应信息的代码所在的行号�?/p>

valgrind --tool=memcheck --leak-check=yes ./example

==6742== Memcheck, a memory error detector for x86-linux.
==6742== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==6742== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==6742== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==6742== For more details, rerun with: -v
==6742== 
==6742== Invalid write of size 4
==6742==    at 0x8048384: f (example.c:6)
==6742==    by 0x80483AC: main (example.c:12)
==6742==  Address 0x1B908050 is 0 bytes after a block of size 40 alloc'd
==6742==    at 0x1B904984: malloc (vg_replace_malloc.c:131)
==6742==    by 0x8048377: f (example.c:5)
==6742==    by 0x80483AC: main (example.c:12)
==6742== 
==6742== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 12 from 1)
==6742== malloc/free: in use at exit: 40 bytes in 1 blocks.
==6742== malloc/free: 1 allocs, 0 frees, 40 bytes allocated.
==6742== For counts of detected errors, rerun with: -v
==6742== searching for pointers to 1 not-freed blocks.
==6742== checked 1360800 bytes.
==6742== 
==6742== 
==6742== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==6742==    at 0x1B904984: malloc (vg_replace_malloc.c:131)
==6742==    by 0x8048377: f (example.c:5)
==6742==    by 0x80483AC: main (example.c:12)
==6742== 
==6742== LEAK SUMMARY:
==6742==    definitely lost: 40 bytes in 1 blocks.
==6742==    possibly lost:   0 bytes in 0 blocks.
==6742==    still reachable: 0 bytes in 0 blocks.
==6742==         suppressed: 0 bytes in 0 blocks.
==6742== Reachable blocks (those to which a pointer was found) are not shown.
==6742== To see them, rerun with: --show-reachable=yes

上面的C�E�序存在两个错误�Q?. 数组下标��界�Q?. 分配的内存没有释放，存在内存泄露的问题。对于错�?�Q�看Valgrind的调试信息片�?

==6742== Invalid write of size 4
==6742==    at 0x8048384: f (example.c:6)
==6742==    by 0x80483AC: main (example.c:12)
==6742==  Address 0x1B908050 is 0 bytes after a block of size 40 alloc'd
==6742==    at 0x1B904984: malloc (vg_replace_malloc.c:131)
==6742==    by 0x8048377: f (example.c:5)

对于错误2�Q�看�q�个

==6742== malloc/free: 1 allocs, 0 frees, 40 bytes allocated.
......
==6742== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==6742==    at 0x1B904984: malloc (vg_replace_malloc.c:131)
==6742==    by 0x8048377: f (example.c:5)
==6742==    by 0x80483AC: main (example.c:12)

T.S Liu 2008-07-01 10:02 发表评论