Valgrind是一个分析内存泄漏非常好用的工具，一般linux设备上都有预装，通过一个实例简单跟大家分享一下。

moov_generator对信号没有进行很好的处理，为了能够使用Valgrind进行检查，必须加上信号处理，这样在终端执行ctrl +c 时，moov_generator可以正常退出。

首先，必须使moov_generator启动在终端，不能通过daemon方式后台启动，Valgrind命令及执行结果如下。

[root@ h264_streamd]# valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./moov_generator -l4

moov_generator运行起来了，和以往不同的是运行在valgrind的环境下。

moov_generator只有在真正干活的时候，才有可能出现那么大的内存泄漏，为了模拟真实的拖拽操作，在另外一台设备上固定host，使用wget抓取：

[root@svn ~]# wget -SO /dev/null http://www.zhoudshu.cn/html/qq/qq.mp4?start=100

--14:32:15--  http://www.zhoudshu.cn/html/qq/qq.mp4?start=100

           => `/dev/null'

正在解析主机 www.zhoudshu.cn... 192.168.100.185

Connecting to www.zhoudshu.cn|192.168.100.185|:80... 已连接。

已发出 HTTP 请求，正在等待回应...

  HTTP/1.0 200 OK

  Date: Thu, 10 Jun 2010 03:13:11 GMT

  Server: Apache/2.0.52 (Red Hat)

  Last-Modified: Fri, 04 Jun 2010 05:54:06 GMT

  ETag: "102fc4-700c98-f370bb80"

  Accept-Ranges: bytes

  Content-Length: 1473318

  Cache-Control: max-age=86400

  Expires: Fri, 11 Jun 2010 03:13:11 GMT

  Content-Type: text/plain; charset=UTF-8

  Age: 11559

  Connection: close

长度：1,473,318 (1.4M) [text/plain]

 

100%[=================================================================================>] 1,473,318     --.--K/s            

 

14:32:15 (62.91 MB/s) - `/dev/null' saved [1473318/1473318]

 

拖拽操作正常，已经走到moov_generator的流程里了，在启动valgrind的终端按下ctrl +c 中断moov_generator，valgrind打出以下信息（为了让大家看到主要内容，我去的了一些无关紧要的信息）：

…………………

==13137== 80 bytes in 4 blocks are definitely lost in loss record 1 of 4

==13137==    at 0x4004405: malloc (vg_replace_malloc.c:149)

==13137==    by 0x804BBBC: trak_build_index (moov.c:732)

==13137==    by 0x804C157: moov_parse (moov.c:1031)

来源：(http://blog.sina.com.cn/s/blog_696a433b0100k92v.html) - 使用valgrind分析内存泄漏（实例）_沧一_新浪博客

==13137==    by 0x804C4B4: moov_seek (moov.c:1164)

==13137==    by 0x8049B7F: moov_data_handler (conn.c:295)

==13137==    by 0x8049DBD: recv_handler (conn.c:360)

==13137==    by 0x9073CB: start_thread (in /lib/tls/libpthread-2.3.4.so)

==13137==    by 0x77EC3D: clone (in /lib/tls/libc-2.3.4.so)

==13137==

==13137==

==13137== 80 bytes in 4 blocks are definitely lost in loss record 2 of 4

==13137==    at 0x4004405: malloc (vg_replace_malloc.c:149)

==13137==    by 0x804B88D: trak_build_index (moov.c:677)

==13137==    by 0x804C157: moov_parse (moov.c:1031)

==13137==    by 0x804C4B4: moov_seek (moov.c:1164)

==13137==    by 0x8049B7F: moov_data_handler (conn.c:295)

==13137==    by 0x8049DBD: recv_handler (conn.c:360)

==13137==    by 0x9073CB: start_thread (in /lib/tls/libpthread-2.3.4.so)

==13137==    by 0x77EC3D: clone (in /lib/tls/libc-2.3.4.so)

==13137==

==13137==

==13137== 352 bytes in 1 blocks are still reachable in loss record 3 of 4

==13137==    at 0x4004405: malloc (vg_replace_malloc.c:149)

==13137==    by 0x70935E: __fopen_internal (in /lib/tls/libc-2.3.4.so)

==13137==    by 0x70BA29: fopen64 (in /lib/tls/libc-2.3.4.so)

==13137==    by 0x804A3F0: writepidFile (h264_streamd.c:190)

==13137==    by 0x804A750: main (h264_streamd.c:240)

==13137==

==13137==

==13137== 408 bytes in 3 blocks are possibly lost in loss record 4 of 4

==13137==    at 0x40056BF: calloc (vg_replace_malloc.c:279)

==13137==    by 0x6A5B0A: _dl_allocate_tls (in /lib/ld-2.3.4.so)

==13137==    by 0x9079DE: pthread_create@@GLIBC_2.1 (in

 

/lib/tls/libpthread-2.3.4.so)

==13137==    by 0x804A775: main (h264_streamd.c:242)

==13137==

==13137== LEAK SUMMARY:

==13137==    definitely lost: 160 bytes in 8 blocks.

==13137==      possibly lost: 408 bytes in 3 blocks.

==13137==    still reachable: 352 bytes in 1 blocks.

==13137==         suppressed: 0 bytes in 0 blocks.

 

“definitely lost”是非常明确的内存泄漏点。

==13137==    at 0x4004405: malloc (vg_replace_malloc.c:149)

==13137==    by 0x804BBBC: trak_build_index (moov.c:732)

可以很明确看到

1.在trak_build_index函数中调用的malloc没有释放。

2.writepidFile时一次文件没有关闭。