상세 내용이 있으나 너무 길어서 눈에 안들어 오는데..
아무튼 요약하면 Direct는 일반 포인터, indirect는 링크드 리스크나 멀티 포인터 인데
이중할당해서 이전 할당을 추적하지 않을 경우라고 보면 될 듯.
Pointer chain AAA Leak Case BBB Leak Case
------------- ------------- -------------
(1) RRR ------------> BBB DR
(2) RRR ---> AAA ---> BBB DR IR
(3) RRR BBB DL
(4) RRR AAA ---> BBB DL IL
(5) RRR ------?-----> BBB (y)DR, (n)DL
(6) RRR ---> AAA -?-> BBB DR (y)IR, (n)DL
(7) RRR -?-> AAA ---> BBB (y)DR, (n)DL (y)IR, (n)IL
(8) RRR -?-> AAA -?-> BBB (y)DR, (n)DL (y,y)IR, (n,y)IL, (_,n)DL
(9) RRR AAA -?-> BBB DL (y)IL, (n)DL
Pointer chain legend:
- RRR: a root set node or DR block
- AAA, BBB: heap blocks
- --->: a start-pointer
- -?->: an interior-pointer
Leak Case legend:
- DR: Directly reachable
- IR: Indirectly reachable
- DL: Directly lost
- IL: Indirectly lost
- (y)XY: it's XY if the interior-pointer is a real pointer
- (n)XY: it's XY if the interior-pointer is not a real pointer
- (_)XY: it's XY in either case
Every possible case can be reduced to one of the above nine. Memcheck merges some of these cases in its output, resulting in the following four leak kinds.
"Still reachable". This covers cases 1 and 2 (for the BBB blocks) above. A start-pointer or chain of start-pointers to the block is found. Since the block is still pointed at, the programmer could, at least in principle, have freed it before program exit. "Still reachable" blocks are very common and arguably not a problem. So, by default, Memcheck won't report such blocks individually.
"Definitely lost". This covers case 3 (for the BBB blocks) above. This means that no pointer to the block can be found. The block is classified as "lost", because the programmer could not possibly have freed it at program exit, since no pointer to it exists. This is likely a symptom of having lost the pointer at some earlier point in the program. Such cases should be fixed by the programmer.
"Indirectly lost". This covers cases 4 and 9 (for the BBB blocks) above. This means that the block is lost, not because there are no pointers to it, but rather because all the blocks that point to it are themselves lost. For example, if you have a binary tree and the root node is lost, all its children nodes will be indirectly lost. Because the problem will disappear if the definitely lost block that caused the indirect leak is fixed, Memcheck won't report such blocks individually by default.
"Possibly lost". This covers cases 5--8 (for the BBB blocks) above. This means that a chain of one or more pointers to the block has been found, but at least one of the pointers is an interior-pointer. This could just be a random value in memory that happens to point into a block, and so you shouldn't consider this ok unless you know you have interior-pointers.[링크 : https://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks]
| "still reachable" (memory that is pointed to by a pointer). "directly lost" (memory that is not pointed to be any live pointer) "indirectly lost" (memory that is pointed to by a pointer that is in memory that is "directly lost) "possibly lost" (memory that is pointed to, but the pointer does not point to the start of the memory). |
[링크 : https://stackoverflow.com/questions/24201561/valgrind-memory-leak-log]
'프로그램 사용 > valgrind' 카테고리의 다른 글
| valgrind callgrind (0) | 2023.07.07 |
|---|---|
| vaglind 사용 (0) | 2022.01.14 |
| valgrind 지원 플랫폼 (0) | 2014.10.15 |
| valgrind GUI frontend- kcachegrind / valkyrie (0) | 2014.10.15 |
