[问题] 在thread里面free memory

楼主: Lipraxde (Lipraxde)   2017-12-05 20:31:17
开发平台(Platform): (Ex: Win10, Linux, ...)
Linux 4.12.13-1-ARCH x86_64
编译器(Ex: GCC, clang, VC++...)+目标环境(跟开发平台不同的话需列出)
gcc 7.2.0
Glibc 2.26
问题(Question):
我想要在main里面malloc后把指标传到thread里,在thread结束前free内存。
结果内存用量会随着操作次数渐渐变大。
程式大致上长像这样:
void *test(void *p)
{
pthread_detach(pthread_self());
free(p);
pthread_exit(NULL);
}
int main(int argc, char *argv[])
{
... other code ...
pthread_t tid;
void *p = malloc(8*1024*1024);
pthread_create(&tid, NULL, test, p);
... other code ...
}
在main里面做了很多次malloc、pthread_create的动作。
有确认过free都有执行到,如果不做malloc、free,单纯建立theard然后退出都正常。
不过两者合在一起用的时候就渐渐的把内存吃掉了。
还有哪里可能有内存没释放到吗?
预期的正确结果(Expected Output):
内存用量不会一直增加
错误结果(Wrong Output):
内存用量渐渐增加
程式码(Code):(请善用置底文网页, 记得排版)
完整的程式:https://ideone.com/SKWT5Q
补充说明(Supplement):
1.执行程式每次被吃的内存量会有一点点不一样。
2.如果是在main里面free的话就不会这样。
作者: jerryh001   2017-12-05 20:44:00
你有检查thread结束了吗? 会不会只是还没切换到那个thread
作者: stupid0319 (征女友)   2017-12-05 21:01:00
你知道8*1024*1024要多少个分页吗感觉pthread_detach放的位置很奇怪...是我的错觉吗假如主线程跑比较多循环,而执行绪卡住这种情况呢?
作者: Qbsuran (Qbsuran)   2017-12-05 21:43:00
detach位置没问题 malloc在某些情况不是thread safe
作者: galic (嘎利)   2017-12-05 21:48:00
detach没问题 他只是改状态而已先报个环境版本上来吧 glibc kernel等等malloc和free从很早开始就一直都是thead safety
作者: jasonwu23 (jasonwu)   2017-12-05 22:01:00
看起来没问题 有没有完整一点的程式码 我想看会一点点增加的版本 有可能别的地方leak
作者: galic (嘎利)   2017-12-05 22:20:00
我猜啦 你配置的内存很大 glibc会改用mmap/munmap这会比小内存用的brk/sbrk方法慢上许多你可以用malloc_stats() 观察小是多小? 默认是超过128*1024就会用mmap
作者: Killercat (杀人猫™)   2017-12-05 23:11:00
valgrind跑一次看看 这个应该抓得出来
作者: galic (嘎利)   2017-12-05 23:19:00
同楼上 我用相似环境跑没问题... 用valgrind跑吧然后你所谓的"内存用量" 是从哪边观察的?
作者: Bencrie   2017-12-06 10:46:00
都要跑 valgrind 了就直接用它测内存用量吧google 一下 valgrind massif
作者: galic (嘎利)   2017-12-06 10:56:00
XD 竟然能用top观察到 这程式跑没几秒still reachable的那个别管他 pthread_create配置的空间thread死掉不会归还 为了效能 下次pthread_create会reuse很多std library实作上都有类似操作 光malloc系列有一大堆
楼主: Lipraxde (Lipraxde)   2017-12-06 13:47:00
pthread会reuse的话应该不会一直无限膨胀阿。如果是在main里面用pthread_join把指标接回来free,过一阵子自己就会变回远本的大小了。(而且没有still reachable)我之后应该会避免这样用吧,虽然变大的速度不快但是看起来真的很不舒服。
作者: galic (嘎利)   2017-12-06 14:00:00
我的意思是你从valgrind观察到的still reachable是pthread走detach的话没办法free pthread create的空间 但是下次pthread create的时候会去reuse 若没被reuse 整个程式结束后 还是能正确的被OS回收 所以这种std library实作造成的常见的still reachable 并不算是真正的memory leak也不该是造成你程式内存不断膨胀的主因
楼主: Lipraxde (Lipraxde)   2017-12-06 14:07:00
恩,了解了…那真正的问题是出在error发生的时候吗?那次的still reachable特别大。
作者: galic (嘎利)   2017-12-06 14:23:00
下"--leak-check=full --show-leak-kinds=reachable"看看看看特别大的那次是谁造成的 XD你提了之后我才想到 你改成全部由malloc的thread来free之后状况就不存在 所以问题可能出在由不同thread来malloc和free
楼主: Lipraxde (Lipraxde)   2017-12-06 14:48:00
我刚刚想到之前用malloc_stats看的时候的确是有一直增加内存用量(每做一次多占用1184bytes),跟用valgrind得到的log不太一样。那个error是偶然间跑出来的,目前只出现一次QQ

Links booklink

Contact Us: admin [ a t ] ucptt.com