pthread_create会导致内存泄露
2011-08-11 15:03
302 查看
转载自:powersaven
这几天一直在调试一个系统,系统的功能就是定时发送数据、接收数据然后解析收到的数据,转换成一定的格式存入数据库中。我为了并发操作,所以每接收到一个数据包,就调用pthread_create函数创建一个默认属性的线程进行处理。
系统一开始运行很正常,但是当接收到第299个数据包时,就发生异常,查看程序日志,得知原来自接收到299个数据包后,就不再解析接收到的数据。我本以为是网络的问题,于是,重启下程序,结果异常发生在了同样的位置。这时,我猜想可能是代码的问题,找到相关代码,如下:
从代码看不出什么异常,由于解析数据是调用pthread_create函数创建一个默认属性的线程进行处理,如果没有解析,那么,应该是pthread_create函数没有创建成功。而pthread_create函数创建失败最可能的原因应该就是系统资源不足,根据经验,线程的默认堆栈大小是1MB,就是说,系统每创建一个线程就要至少提供1MB的内存,那么,创建线程失败,极有可能就是内存不够用了。从代码中看不出有内存泄露的现象,有malloc的地方就会有free对应。而仍然出现问题,那么,唯一的解释就是pthread_create会导致内存泄露!pthread_create创建的线程结束后,系统并未回收其资源,从而导致了泄露。
然后从网上查了相关资料如下:
线程的分离状态决定一个线程以什么样的方式来终止自己。线程的默认属性是非分离状态,这种情况下,原有的线程等待创建的线程结束。只有当pthread_join()函数返回时,创建的线程才算终止,才能释放自己占用的系统资源。而分离线程不是这样子的,它没有被其他的线程所等待,自己运行结束了,线程也就终止了,马上释放系统资源。程序员应该根据自己的需要,选择适当的分离状态。
从上面的描述中可以得知如果调用pthread_create函数创建一个默认非分离状态的线程,如果不用pthread_join()函数,线程结束时并不算终止,所以仍然会占用系统资源。这里有如下几种方法解决这个问题:
1.使用pthread_join()函数回收相关内存区域。
2.可以调用 pthread_detach() 函数分离线程。
当然,也可以在 thread function 中调用。
3.使用线程属性。
根据实际需要,任选其一即可。
ps:最后,我写了个测试程序,然后用valgrind检查了一下。
测试程序:
编译链接:
[root@localhost ~]# gcc -g b.c -o b -lpthread
然后,用valgrind进行内存检查
[root@localhost ~]# valgrind --tool=memcheck --leak-check=full ./b
==20980== Memcheck, a memory error detector
==20980== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==20980== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==20980== Command: ./b
==20980==
ok
==20980==
==20980== HEAP SUMMARY:
==20980== in use at exit: 272 bytes in 1 blocks
==20980== total heap usage: 1 allocs, 0 frees, 272 bytes allocated
==20980==
==20980== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==20980== at 0x4C1F1A0: calloc (vg_replace_malloc.c:418)
==20980== by 0x4010422: _dl_allocate_tls (in /lib64/ld-2.7.so)
==20980== by 0x4E2AB52: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.7.so)
==20980== by 0x40059E: main (b.c:13)
==20980==
==20980== LEAK SUMMARY:
==20980== definitely lost: 0 bytes in 0 blocks
==20980== indirectly lost: 0 bytes in 0 blocks
==20980== possibly lost: 272 bytes in 1 blocks
==20980== still reachable: 0 bytes in 0 blocks
==20980== suppressed: 0 bytes in 0 blocks
==20980==
==20980== For counts of detected and suppressed errors, rerun with: -v
==20980== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
确实有内存泄露。
修改测试程序:
编译链接:
[root@localhost ~]# gcc -g b.c -o b -lpthread
然后,用valgrind进行内存检查
[root@localhost ~]# valgrind --tool=memcheck --leak-check=full ./b
==21013== Memcheck, a memory error detector
==21013== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21013== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==21013== Command: ./b
==21013==
ok
==21013==
==21013== HEAP SUMMARY:
==21013== in use at exit: 0 bytes in 0 blocks
==21013== total heap usage: 1 allocs, 1 frees, 272 bytes allocated
==21013==
==21013== All heap blocks were freed -- no leaks are possible
==21013==
==21013== For counts of detected and suppressed errors, rerun with: -v
==21013== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
不join的pthread记得detach哦
这几天一直在调试一个系统,系统的功能就是定时发送数据、接收数据然后解析收到的数据,转换成一定的格式存入数据库中。我为了并发操作,所以每接收到一个数据包,就调用pthread_create函数创建一个默认属性的线程进行处理。
系统一开始运行很正常,但是当接收到第299个数据包时,就发生异常,查看程序日志,得知原来自接收到299个数据包后,就不再解析接收到的数据。我本以为是网络的问题,于是,重启下程序,结果异常发生在了同样的位置。这时,我猜想可能是代码的问题,找到相关代码,如下:
while(1) { len =recvfrom(sock, buf, MAXPACKETSIZE, 0,(structsockaddr*)&c_addr,&addr_len); ....... targ =(struct threadarg*)malloc(sizeof(struct threadarg)); memset(targ, 0,sizeof(struct threadarg)); targ->len = len; targ->ip =(int)c_addr.sin_addr.s_addr; memcpy(targ->buffer, buf, len); printf("received\n"); //注:targ在线程中会被free掉。 pthread_create(&tid,NULL, insertToList,(void*)targ); } |
然后从网上查了相关资料如下:
线程的分离状态决定一个线程以什么样的方式来终止自己。线程的默认属性是非分离状态,这种情况下,原有的线程等待创建的线程结束。只有当pthread_join()函数返回时,创建的线程才算终止,才能释放自己占用的系统资源。而分离线程不是这样子的,它没有被其他的线程所等待,自己运行结束了,线程也就终止了,马上释放系统资源。程序员应该根据自己的需要,选择适当的分离状态。
从上面的描述中可以得知如果调用pthread_create函数创建一个默认非分离状态的线程,如果不用pthread_join()函数,线程结束时并不算终止,所以仍然会占用系统资源。这里有如下几种方法解决这个问题:
1.使用pthread_join()函数回收相关内存区域。
pthread_t tid; void* state; pthread_create(&tid,NULL,test,NULL); pthread_join(tid,&state); |
pthread_t tid; pthread_create(&tid,NULL,test,NULL); pthread_detach(tid); |
void*test(void*arg) { ..... pthread_detach(pthread_self()); returnNULL; } |
pthread_attr_t attr; pthread_t tid; pthread_attr_init(&attr); pthread_attr_setdetachstate(&attr,PTHREAD_CREATE_DETACHED); pthread_create(&tid,&attr,test,NULL); sleep(3);//等待线程结束 pthread_attr_destroy(&attr); |
ps:最后,我写了个测试程序,然后用valgrind检查了一下。
测试程序:
#include<pthread.h> #include<stdio.h> void*test() { printf("ok\n"); return; } int main(int argc,char** argv) { pthread_t tid; pthread_create(&tid,NULL,test,NULL); //pthread_join(tid, NULL); return 1; } |
[root@localhost ~]# gcc -g b.c -o b -lpthread
然后,用valgrind进行内存检查
[root@localhost ~]# valgrind --tool=memcheck --leak-check=full ./b
==20980== Memcheck, a memory error detector
==20980== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==20980== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==20980== Command: ./b
==20980==
ok
==20980==
==20980== HEAP SUMMARY:
==20980== in use at exit: 272 bytes in 1 blocks
==20980== total heap usage: 1 allocs, 0 frees, 272 bytes allocated
==20980==
==20980== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==20980== at 0x4C1F1A0: calloc (vg_replace_malloc.c:418)
==20980== by 0x4010422: _dl_allocate_tls (in /lib64/ld-2.7.so)
==20980== by 0x4E2AB52: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.7.so)
==20980== by 0x40059E: main (b.c:13)
==20980==
==20980== LEAK SUMMARY:
==20980== definitely lost: 0 bytes in 0 blocks
==20980== indirectly lost: 0 bytes in 0 blocks
==20980== possibly lost: 272 bytes in 1 blocks
==20980== still reachable: 0 bytes in 0 blocks
==20980== suppressed: 0 bytes in 0 blocks
==20980==
==20980== For counts of detected and suppressed errors, rerun with: -v
==20980== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
确实有内存泄露。
修改测试程序:
#include<pthread.h> #include<stdio.h> void*test() { printf("ok\n"); return; } int main(int argc,char** argv) { pthread_t tid; pthread_create(&tid,NULL,test,NULL); pthread_join(tid,NULL); return 1; } |
[root@localhost ~]# gcc -g b.c -o b -lpthread
然后,用valgrind进行内存检查
[root@localhost ~]# valgrind --tool=memcheck --leak-check=full ./b
==21013== Memcheck, a memory error detector
==21013== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21013== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==21013== Command: ./b
==21013==
ok
==21013==
==21013== HEAP SUMMARY:
==21013== in use at exit: 0 bytes in 0 blocks
==21013== total heap usage: 1 allocs, 1 frees, 272 bytes allocated
==21013==
==21013== All heap blocks were freed -- no leaks are possible
==21013==
==21013== For counts of detected and suppressed errors, rerun with: -v
==21013== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
不join的pthread记得detach哦
相关文章推荐
- pthread_create会导致内存泄露
- pthread_create会导致内存泄露
- 解决使用pthread_create函数造成的内存泄露
- 解决使用pthread_create函数造成的内存泄露
- 解决使用pthread_create函数造成的内存泄露
- pthread_create 导致内存泄露
- 避免使用不当pthread_create函数造成内存泄露
- 深度:ARC会导致的内存泄露
- php 把数组作为一个元素添加到自己会导致暂时的内存泄露
- ios 下CGImageCreateWithImageInRect 内存泄露
- android中不小心使用静态变量会导致内存泄露
- 内存溢出:java.lang.OutOfMemoryError: pthread_create (stack size 131072 bytes) failed: Out of memory
- 正确使用pthread_create,防止内存泄漏
- pthread_create后没有detach导致内存持续增长
- 什么情况下会导致内存泄露
- GDI对象错误:CBRUSH释放、CreateSolidBrush的内存释放与内存泄露问题及其解决方法
- 解决了一个隐蔽的内存泄漏——pthread_create后没有detach导致内存持续增长
- pthread_create会导致内存泄露
- pthread_create会导致内存泄露
- 内存溢出 out of memory 内存泄露 memory leak ;memory leak会最终会导致out of memory!