作者Lipraxde (静夜)
看板C_and_CPP
标题[问题] 在thread里面free memory
时间Tue Dec 5 20:31:17 2017
开发平台(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的话就不会这样。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.136.241.143
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1512477084.A.9EE.html
1F：推 jerryh001: 你有检查thread结束了吗？ 会不会只是还没切换到那个th 12/05 20:44
2F：→ jerryh001: read 12/05 20:44
3F：→ stupid0319: 你知道8*1024*1024要多少个分页吗 12/05 21:01
我有cat /proc/${pid}/status看过，最後Threads=1。
malloc要多少个分页会有影响吗？我设这麽大是想说如果没free到应该会很明显。
不过我的程式不会占到那麽大，这个动作大概做1000次才会多吃1Mib左右的空间。
※ 编辑: Lipraxde (223.136.241.143), 12/05/2017 21:15:24
4F：→ stupid0319: 感觉pthread_detach放的位置很奇怪...是我的错觉吗 12/05 21:09
我是看网路上有人这样用 OwO
※ 编辑: Lipraxde (223.136.241.143), 12/05/2017 21:21:50
5F：→ stupid0319: 假如主线程跑比较多回圈,而执行绪卡住这种情况呢? 12/05 21:37
不太懂你的意思，我都在pthread_exit前一道指令free的，如果有thread卡住的话剩下的
thread应该不会只有1条。
※ 编辑: Lipraxde (223.136.241.143), 12/05/2017 21:45:44
6F：推 Qbsuran: detach位置没问题 malloc在某些情况不是thread safe 12/05 21:43
我有对malloc、free加互斥锁过，结果一样。(这个example比较单纯，应该还好)
※ 编辑: Lipraxde (223.136.241.143), 12/05/2017 21:47:59
7F：→ galic: detach没问题 他只是改状态而已 12/05 21:48
8F：→ galic: 先报个环境版本上来吧 glibc kernel等等 12/05 21:49
OK，glibc版本2.26(其他有更新在上面)
9F：→ galic: malloc和free从很早开始就一直都是thead safety 12/05 21:49
10F：推 jasonwu23: 看起来没问题 有没有完整一点的程式码 我想看会一点点 12/05 22:01
11F：→ jasonwu23: 增加的版本 有可能别的地方leak 12/05 22:01
https://ideone.com/SKWT5Q
这个是我把遇到的情况简化过的，它的确会慢慢变大，for回圈多跑个几次就看的出来。
还是你是想看我的作业>///<，已经被我改成在main里面free了 @w@
※ 编辑: Lipraxde (223.136.241.143), 12/05/2017 22:14:17
12F：→ galic: 我猜啦 你配置的记忆体很大 glibc会改用mmap/munmap 12/05 22:20
13F：→ galic: 这会比小记忆体用的brk/sbrk方法慢上许多 12/05 22:20
14F：→ galic: 你可以用malloc_stats() 观察 12/05 22:21
用malloc_stats看了之後觉得很奇怪，每次in use bytes都增加1184 bytes，那是啥？
是说我试过配置较小的记忆体了，不过用量还是会慢慢变大...
※ 编辑: Lipraxde (223.136.241.143), 12/05/2017 22:41:25
15F：→ galic: 小是多小? 预设是超过128*1024就会用mmap 12/05 22:46
8个byte~
※ 编辑: Lipraxde (223.136.241.143), 12/05/2017 23:04:45
16F：推 Killercat: valgrind跑一次看看 这个应该抓得出来 12/05 23:11
17F：→ galic: 同楼上 我用相似环境跑没问题... 用valgrind跑吧 12/05 23:19
18F：→ galic: 然後你所谓的"记忆体用量" 是从哪边观察的? 12/05 23:20
用top跟你说的malloc_stats看的，不然我明天用valgrind、换台电脑试试看好了。
(好像在哪边看到说free不一定会马上还给系统，不过应该不是这个问题。因为我free完用
malloc可以得到相同的位置，可是还是会越吃越多Q_Q)
※ 编辑: Lipraxde (223.136.241.143), 12/05/2017 23:25:29
19F：推 Bencrie: 都要跑 valgrind 了就直接用它测记忆体用量吧 12/06 10:46
20F：→ Bencrie: google 一下 valgrind massif 12/06 10:47
21F：→ galic: XD 竟然能用top观察到 这程式跑没几秒 12/06 10:56
改成无穷回圈一直跑就能看到它越来越大只了。
用valgrind看有时候有still reachable: 1,612 bytes in 4 blocks，有时候又没有。
偶尔还底下还会出现：ERROR SUMMARY: 1 errors from 1 contexts。
※ 编辑: Lipraxde (140.118.202.43), 12/06/2017 12:05:53
22F：→ galic: still reachable的那个别管他 pthread_create配置的空间 12/06 13:29
23F：→ galic: thread死掉不会归还 为了效能 下次pthread_create会reuse 12/06 13:30
24F：→ galic: 很多std library实作上都有类似操作 光malloc系列有一大堆 12/06 13:31
25F：→ Lipraxde: pthread会reuse的话应该不会一直无限膨胀阿。 12/06 13:47
26F：→ Lipraxde: 如果是在main里面用pthread_join把指标接回来free，过一 12/06 13:47
27F：→ Lipraxde: 阵子自己就会变回远本的大小了。(而且没有still reachab 12/06 13:47
28F：→ Lipraxde: le) 12/06 13:47
29F：→ Lipraxde: 我之後应该会避免这样用吧，虽然变大的速度不快但是看起 12/06 13:47
30F：→ Lipraxde: 来真的很不舒服。 12/06 13:47
31F：→ galic: 我的意思是你从valgrind观察到的still reachable是pthread 12/06 14:00
32F：→ galic: 走detach的话没办法free pthread create的空间 但是下次 12/06 14:01
33F：→ galic: pthread create的时候会去reuse 若没被reuse 整个程式结束 12/06 14:02
34F：→ galic: 後 还是能正确的被OS回收 所以这种std library实作造成的 12/06 14:02
35F：→ galic: 常见的still reachable 并不算是真正的memory leak 12/06 14:02
36F：→ galic: 也不该是造成你程式记忆体不断膨胀的主因 12/06 14:03
37F：→ Lipraxde: 恩，了解了…那真正的问题是出在error发生的时候吗？那 12/06 14:07
38F：→ Lipraxde: 次的still reachable特别大。 12/06 14:07
39F：→ galic: 下"--leak-check=full --show-leak-kinds=reachable"看看 12/06 14:23
40F：→ galic: 看看特别大的那次是谁造成的 XD 12/06 14:24
41F：→ galic: 你提了之後我才想到 你改成全部由malloc的thread来free之後 12/06 14:25
42F：→ galic: 状况就不存在 所以问题可能出在由不同thread来malloc和free 12/06 14:25
43F：→ Lipraxde: 我刚刚想到之前用malloc_stats看的时候的确是有一直增加 12/06 14:48
44F：→ Lipraxde: 记忆体用量(每做一次多占用1184bytes)，跟用valgrind得 12/06 14:48
45F：→ Lipraxde: 到的log不太一样。 12/06 14:48
46F：→ Lipraxde: 那个error是偶然间跑出来的，目前只出现一次QQ 12/06 14:48