valgrind显示“x blocks are still reachable in loss record x of x”
来源:互联网 发布:python基础教程廖雪峰 编辑:程序博客网 时间:2024/05/22 05:25
用valgrind检测内存泄露的时候,报的都是x blocks are still reachable in loss record x of x
一直不明白这是什么错误,然后上网查了一下,受益匪浅。明白了内存泄露到底是怎么一回事情。
There is more than one way to define "memory leak". In particular, there are two primary definitions of "memory leak" that are in common usage among programmers.
The first commonly used definition of "memory leak" is, "Memory was allocated and was not subsequently freed before the program terminated." However, many programmers (rightly) argue that certain types of memory leaks that fit this definition don't actually pose any sort of problem, and therefore should not be considered true "memory leaks".
An arguably stricter (and more useful) definition of "memory leak" is, "Memory was allocated and can not be subsequently freed because the program no longer has any pointers to the allocated memory block." In other words, you cannot free memory that you no longer have any pointers to. Such memory is therefore a "memory leak". Valgrind uses this stricter definition of the term "memory leak". This is the type of leak which can potentially cause significant heap depletion, especially for long lived processes.
The "still reachable" category within Valgrind's leak report refers to allocations that fit only the first definition of "memory leak". These blocks were not freed, but they could have been freed (if the programmer had wanted to) because the program still was keeping track of pointers to those memory blocks.
In general, there is no need to worry about "still reachable" blocks. They don't pose the sort of problem that true memory leaks can cause. For instance, there is normally no potential for heap exhaustion from "still reachable" blocks. This is because these blocks are usually one-time allocations, references to which are kept throughout the duration of the process's lifetime. While you could go through and ensure that your program frees all allocated memory, there is usually no practical benefit from doing so since the operating system will reclaim all of the process's memory after the process terminates, anyway. Contrast this with true memory leaks which, if left unfixed, could cause a process to run out of memory if left running long enough, or will simply cause a process to consume far more memory than is necessary.
Probably the only time it is useful to ensure that all allocations have matching "frees" is if your leak detection tools cannot tell which blocks are "still reachable" (but Valgrind can do this) or if your operating system doesn't reclaim all of a terminating process's memory (all platforms which Valgrind has been ported to do this).
一直不明白这是什么错误,然后上网查了一下,受益匪浅。明白了内存泄露到底是怎么一回事情。
There is more than one way to define "memory leak". In particular, there are two primary definitions of "memory leak" that are in common usage among programmers.
The first commonly used definition of "memory leak" is, "Memory was allocated and was not subsequently freed before the program terminated." However, many programmers (rightly) argue that certain types of memory leaks that fit this definition don't actually pose any sort of problem, and therefore should not be considered true "memory leaks".
An arguably stricter (and more useful) definition of "memory leak" is, "Memory was allocated and can not be subsequently freed because the program no longer has any pointers to the allocated memory block." In other words, you cannot free memory that you no longer have any pointers to. Such memory is therefore a "memory leak". Valgrind uses this stricter definition of the term "memory leak". This is the type of leak which can potentially cause significant heap depletion, especially for long lived processes.
The "still reachable" category within Valgrind's leak report refers to allocations that fit only the first definition of "memory leak". These blocks were not freed, but they could have been freed (if the programmer had wanted to) because the program still was keeping track of pointers to those memory blocks.
In general, there is no need to worry about "still reachable" blocks. They don't pose the sort of problem that true memory leaks can cause. For instance, there is normally no potential for heap exhaustion from "still reachable" blocks. This is because these blocks are usually one-time allocations, references to which are kept throughout the duration of the process's lifetime. While you could go through and ensure that your program frees all allocated memory, there is usually no practical benefit from doing so since the operating system will reclaim all of the process's memory after the process terminates, anyway. Contrast this with true memory leaks which, if left unfixed, could cause a process to run out of memory if left running long enough, or will simply cause a process to consume far more memory than is necessary.
Probably the only time it is useful to ensure that all allocations have matching "frees" is if your leak detection tools cannot tell which blocks are "still reachable" (but Valgrind can do this) or if your operating system doesn't reclaim all of a terminating process's memory (all platforms which Valgrind has been ported to do this).
- valgrind显示“x blocks are still reachable in loss record x of x”
- valgrind--still reachable
- HttpClient4.X Invalid use of SingleClientConnManager: connection still allocated问题
- HttpClient4.X Invalid use of SingleClientConnManager: connection still allocated
- X RECORD extension example
- X++ CODE TO GENERATE ALERT FOR RECORD IN DAX 2011
- nfs server x.x.x.x not response,still trying...解决
- Integral of sin(x)/x
- List of X$ Tables and how the names are derived
- X窗口 X 事件 X显示
- $X
- X
- X
- X
- x
- x
- X
- /x
- unionfs安装到Linux内核
- 为什么程序员喜欢在深夜编程?
- IOS applicationDidEnterBackground
- eclipse+jbpm5+jboss的集成配置
- DundasWebChart在IIS7.5 windows2008 64位版发布时不能正常显示
- valgrind显示“x blocks are still reachable in loss record x of x”
- 利用脚本解放自己,让脚本帮我做事2 -- 帮自己寻找不在SVN控制中的文件
- give two sorted array, find the k-th smallest element of union of A and B
- 求一个学院教材管理系统
- WEB压力测试
- OCX--VC2005开发OCX
- WebService系列博客{十}[CXF简单案例实现]
- 关于软件测试的问与答(与神仙的对话)
- boost日期、时间操作