月份:2013年5月

Linux C/C++ 内存泄漏检测工具:Valgrind

Valgrind 是一款 Linux下(支持 x86、x86_64和ppc32)程序的内存调试工具,它可以对编译后的二进制程序进行内存使用监测(C语言中的malloc和free,以及C++中的new和delete),找出内存泄漏问题。

Valgrind 中包含的 Memcheck 工具可以检查以下的程序错误:

使用未初始化的内存 (Use of uninitialised memory)
使用已经释放了的内存 (Reading/writing memory after it has been free’d)
使用超过malloc分配的内存空间(Reading/writing off the end of malloc’d blocks)
对堆栈的非法访问 (Reading/writing inappropriate areas on the stack)
申请的空间是否有释放 (Memory leaks – where pointers to malloc’d blocks are lost forever)
malloc/free/new/delete申请和释放内存的匹配(Mismatched use of malloc/new/new [] vs free/delete/delete [])
src和dst的重叠(Overlapping src and dst pointers in memcpy() and related functions)
重复free

1、编译安装 Valgrind:


wget http://valgrind.org/downloads/valgrind-3.4.1.tar.bz2
tar xvf valgrind-3.4.1.tar.bz2
cd valgrind-3.4.1/
./configure --prefix=/usr/local/webserver/valgrind
make
make install

2、使用示例:对“ls”程序进程检查,返回结果中的“definitely lost: 0 bytes in 0 blocks.”表示没有内存泄漏。


[root@xoyo42 /]#/usr/local/webserver/valgrind/bin/valgrind --tool=memcheck --leak-check=full ls /
==1157== Memcheck, a memory error detector.
==1157== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==1157== Using LibVEX rev 1884, a library for dynamic binary translation.
==1157== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==1157== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==1157== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==1157== For more details, rerun with: -v
==1157==
bin   data0  dev  home  lib64       media  mnt  opt   root  selinux  sys       tcsql.db.idx.pkey.dec  ttserver.pid  var
boot  data1  etc  lib   lost+found  misc   net  proc  sbin  srv      tcsql.db  tmp                    usr
==1157==
==1157== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==1157== malloc/free: in use at exit: 28,471 bytes in 36 blocks.
==1157== malloc/free: 166 allocs, 130 frees, 51,377 bytes allocated.
==1157== For counts of detected errors, rerun with: -v
==1157== searching for pointers to 36 not-freed blocks.
==1157== checked 174,640 bytes.
==1157==
==1157== LEAK SUMMARY:
==1157==    definitely lost: 0 bytes in 0 blocks.
==1157==      possibly lost: 0 bytes in 0 blocks.
==1157==    still reachable: 28,471 bytes in 36 blocks.
==1157==         suppressed: 0 bytes in 0 blocks.
==1157== Reachable blocks (those to which a pointer was found) are not shown.
==1157== To see them, rerun with: --leak-check=full --show-reachable=yes

3、使用示例:对一个使用libevent库编写的“httptest”程序进程检查,返回结果中的“definitely lost: 255 bytes in 5 blocks.”表示发生内存泄漏。


[root@xoyo42 tcsql-0.1]# /usr/local/webserver/valgrind/bin/valgrind --tool=memcheck --leak-check=full ./httptest
==1274== Memcheck, a memory error detector.
==1274== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==1274== Using LibVEX rev 1884, a library for dynamic binary translation.
==1274== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==1274== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==1274== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==1274== For more details, rerun with: -v
==1274==
==1274== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1005 from 2)
==1274== malloc/free: in use at exit: 402,291 bytes in 74 blocks.
==1274== malloc/free: 15,939 allocs, 15,865 frees, 6,281,523 bytes allocated.
==1274== For counts of detected errors, rerun with: -v
==1274== searching for pointers to 74 not-freed blocks.
==1274== checked 682,468,160 bytes.
==1274==
==1274== 255 bytes in 5 blocks are definitely lost in loss record 17 of 32
==1274==    at 0x4A05FBB: malloc (vg_replace_malloc.c:207)
==1274==    by 0x3C1D809BC6: evhttp_decode_uri (http.c:2105)
==1274==    by 0x401C75: tcsql_handler (in /data0/tcsql/cankao/tcsql-0.1/tcsql)
==1274==    by 0x3C1D80C88F: evhttp_get_body (http.c:1582)
==1274==    by 0x3C1D8065F7: event_base_loop (event.c:392)
==1274==    by 0x403E2F: main (in /data0/tcsql/cankao/tcsql-0.1/tcsql)
==1274==
==1274== LEAK SUMMARY:
==1274==    definitely lost: 255 bytes in 5 blocks.
==1274==      possibly lost: 0 bytes in 0 blocks.
==1274==    still reachable: 402,036 bytes in 69 blocks.
==1274==         suppressed: 0 bytes in 0 blocks.
==1274== Reachable blocks (those to which a pointer was found) are not shown.
==1274== To see them, rerun with: --leak-check=full --show-reachable=yes

检查httptest程序,发现有一处“char *decode_uri = evhttp_decode_uri(evhttp_request_uri(req));”中的“decode_uri”没有被free,再程序处理完成后加上“free(decode_uri);”后,再使用Valgrind检查,结果已经是“definitely lost: 0 bytes in 0 blocks.”。

转自:http://www.s135.com/post/419/


实时查看linux网卡流量

将下列脚本保存为可执行脚本文件,比如叫traff.sh。

1、本脚本可自定义欲查看接口,精确到小数,并可根据流量大小灵活显示单位。
2、此脚本的采集间隔为1秒。
3、此脚本不需要额外再安装软件,可在急用情况下应付一下,比如临时想看一下是否有流量通过,大概为多少等。
4、一些流量查看软件由于计算的精确度不同,所以与此脚本显示的数值不可能一致,此脚本的显示结果与du meter对比过,相差很小。还有就是传输工具本身显示的传输速度并不准确。
用法为:
1、chmod +x ./traff.sh 将文件改成可执行脚本。
2、./traff.sh eth0即可开始监看接口eth0流量,按ctrl+c退出。


#!/bin/bash
 while [ "1" ]
 do
 eth=$1
 RXpre=$(cat /proc/net/dev | grep $eth | tr : " " | awk '{print $2}')
 TXpre=$(cat /proc/net/dev | grep $eth | tr : " " | awk '{print $10}')
 sleep 1
 RXnext=$(cat /proc/net/dev | grep $eth | tr : " " | awk '{print $2}')
 TXnext=$(cat /proc/net/dev | grep $eth | tr : " " | awk '{print $10}')
 clear
 echo -e "\t RX `date +%k:%M:%S` TX"
 RX=$((${RXnext}-${RXpre}))
 TX=$((${TXnext}-${TXpre}))

if [[ $RX -lt 1024 ]];then
 RX="${RX}B/s"
 elif [[ $RX -gt 1048576 ]];then
 RX=$(echo $RX | awk '{print $1/1048576 "MB/s"}')
 else
 RX=$(echo $RX | awk '{print $1/1024 "KB/s"}')
 fi

if [[ $TX -lt 1024 ]];then
 TX="${TX}B/s"
 elif [[ $TX -gt 1048576 ]];then
 TX=$(echo $TX | awk '{print $1/1048576 "MB/s"}')
 else
 TX=$(echo $TX | awk '{print $1/1024 "KB/s"}')
 fi

echo -e "$eth \t $RX $TX "
 done


jni内存泄露

在c++中new的对象,如果不返回java,必须用release掉,否则内存泄露。包括NewStringUTF,NewObject
。如果返回java不必release,java会自己回收。

jstring jstr = env->NewStringUTF((*p).sess_id);

env->DeleteLocalRef( jstr);

jobject jobj = env->NewObject(clazz,midInit);
return jobj;

内存泄露可以先从windows资源管理器中,看到随程序运行,内存不断增长的趋势,具体可以用hp jmeter检测在运行程序时,加jvm参数 -Xrunhprof:heap=all,cutoff=0 ,生成java.hprof.txt,用jmeter打开,Metric -> Residual Objects (Count),可以看到未回收的对象,选中要查看的对象,点Mark记录下要查看的对象,Window -> New Window 打开新窗口,用Metric -> Reference Graph Tree,然后点Find Immediately可以看到对象被哪里引用。

找出内存泄漏另一方法

程序有内存泄漏的第一个迹象通常是它抛出一个 DE>OutOfMemoryErrorDE>,或者因为频繁的垃圾收集而表现出糟糕的性能。幸运的是,垃圾收集可以提供能够用来诊断内存泄漏的大量信息。如果以 DE>-verbose:gcDE> 或者 DE>-XloggcDE> 选项调用 JVM,那么每次 GC 运行时在控制台上或者日志文件中会打印出一个诊断信息,包括它所花费的时间、当前堆使用情况以及恢复了多少内存。记录 GC 使用情况并不具有干扰性,因此如果需要分析内存问题或者调优垃圾收集器,在生产环境中默认启用 GC 日志是值得的。

有工具可以利用 GC 日志输出并以图形方式将它显示出来,JTune 就是这样的一种工具(请参阅 参考资料)。观察 GC 之后堆大小的图,可以看到程序内存使用的趋势。对于大多数程序来说,可以将内存使用分为两部分:baseline 使用和current load 使用。对于服务器应用程序,baseline 使用就是应用程序在没有任何负荷、但是已经准备好接受请求时的内存使用,current load 使用是在处理请求过程中使用的、但是在请求处理完成后会释放的内存。只要负荷大体上是恒定的,应用程序通常会很快达到一个稳定的内存使用水平。如果在应用程序已经完成了其初始化并且负荷没有增加的情况下,内存使用持续增加,那么程序就可能在处理前面的请求时保留了生成的对象。

 

图 1 显示  GC 之后应用程序堆大小随着时间的变化图。上升趋势是存在内存泄漏的警示信号。(在真实的应用程序中,坡度不会这么大,但是在收集了足够长时间的 GC 数据后,上升趋势通常会表现得很明显。)
图 1. 持续上升的内存使用趋势

确信有了内存泄漏后,下一步就是找出哪种对象造成了这个问题。所有内存分析器都可以生成按照对象类进行分解的堆快照。有一些很好的商业堆分析工具,但是找出内存泄漏不一定要花钱买这些工具 —— 内置的 DE>hprofDE> 工具也可完成这项工作。要使用 DE>hprofDE> 并让它跟踪内存使用,需要以 DE>-Xrunhprof:heap=sitesDE> 选项调用 JVM。

清单 3 显示分解了应用程序内存使用的 DE>hprofDE> 输出的相关部分。(DE>hprofDE> 工具在应用程序退出时,或者用 DE>kill -3DE> 或在 Windows 中按 Ctrl+Break 时生成使用分解。)注意两次快照相比,DE>Map.EntryDE>、DE>TaskDE> 和 DE>int[]DE> 对象有了显著增加。

请参阅 清单 3

清单 4 展示了 DE>hprofDE> 输出的另一部分,给出了 DE>Map.EntryDE> 对象的分配点的调用堆栈信息。这个输出告诉我们哪些调用链生成了 DE>Map.EntryDE> 对象,并带有一些程序分析,找出内存泄漏来源一般来说是相当容易的。
清单 4. HPROF 输出,显示 Map.Entry 对象的分配点

DE>    TRACE 300446:   java.util.HashMap$Entry.<init>(<Unknown Source>:Unknown line)   java.util.HashMap.addEntry(<Unknown Source>:Unknown line)   java.util.HashMap.put(<Unknown Source>:Unknown line)   java.util.Collections$SynchronizedMap.put(<Unknown Source>:Unknown line)   com.quiotix.dummy.MapLeaker.newTask(MapLeaker.java:48)   com.quiotix.dummy.MapLeaker.main(MapLeaker.java:64)  DE>

另外
jstring jstr = (jstring)env->CallObjectMethod(authenRequest, mid_authenReq_getSdId_S);
env->GetStringUTFRegion(jstr,0,env->GetStringLength(jstr),authenReq.sd_id);
当jstr是null时,env->GetStringLength(jstr)会出错,导致jvm崩溃

FROM: http://www.blogjava.net/neumqp/archive/2006/03/02/33152.html


使用maven建立多模块web项目

有时候我们需要创建多模块maven项目,即将传统的ssh项目中的model,dao,manager,service,view层划分成单个的maven module。具体步骤如下:

首先前提是必须安装好maven,在安装好maven之后进入命令行窗口,转到你所在的workspace目录

1.   生成父级工程

 

命令:

wanghaihua@wanghaihua-pc:~/workspace$ mvn archetype:create -DgroupId=com.duanqu -DartifactId=duanqu_2.0 

 

打开duanqu_2.0目录删除src文件夹,打开pom.xml,将packaging属性修改为pom(表示为父工程)

2.   生成子工程:

进入duanqu_2.0目录:

例如生成domain子工程

 

命令

wanghaihua@wanghaihua-pc:~/workspace$ mvn archetype:create -DgroupId=com.duanqu -DartifactId=duanqu-domain -Dpackage=com.duanqu.domain

 

   特例(web子项目)

 

命令

wanghaihua@wanghaihua-pc:~/workspace$ mvn archetype:create -DgroupId=com.duanqu -DartifactId=duanqu-web -Dpackage=com.duanqu.web -DarchetypeArtifactId=maven-archetype-webapp 

 

其中 -DarchetypeArtifactId=maven-archetype-webapp表示生成的子项目为web工程

 

   3.转换成eclipse项目:

 

命令

mvn eclipse:clean eclipse:eclipse

 

另:mvn eclipse:clean eclipse:eclipse -Dwtpversion=1.0据说可以完成自动热部署。还没试过。。