这个
accepted answer
不太正确。特别地
只有
间接泄漏。当构建并泄漏自引用结构时,可能会出现这种情况。
例子:
#include <malloc.h>
struct Foo {
struct Foo *other;
};
void fn(int depth)
{
if (depth > 0) {
// recursion is only necessary to avoid LSan finding "stray" pointers
// and not reporting any leaks at all.
fn(depth - 1);
} else {
struct Foo *f1 = malloc(sizeof(*f1));
struct Foo *f2 = malloc(sizeof(*f2));
f1->other = f2;
f2->other = f1;
}
}
int main()
{
fn(10);
return 0;
}
clang -g -fsanitize=address t.c && ./a.out
=================================================================
==845196==ERROR: LeakSanitizer: detected memory leaks
Indirect leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x49832d in malloc (/tmp/a.out+0x49832d)
#1 0x4c7f8e in fn /tmp/t.c:15:22
#2 0x4c7f71 in fn /tmp/t.c:12:5
#3 0x4c7f71 in fn /tmp/t.c:12:5
#4 0x4c7f71 in fn /tmp/t.c:12:5
#5 0x4c7f71 in fn /tmp/t.c:12:5
#6 0x4c7f71 in fn /tmp/t.c:12:5
#7 0x4c7f71 in fn /tmp/t.c:12:5
#8 0x4c7f71 in fn /tmp/t.c:12:5
#9 0x4c7f71 in fn /tmp/t.c:12:5
#10 0x4c7f71 in fn /tmp/t.c:12:5
#11 0x4c7f71 in fn /tmp/t.c:12:5
#12 0x4c8028 in main /tmp/t.c:23:3
#13 0x7f147d3a7d09 in __libc_start_main csu/../csu/libc-start.c:308:16
Indirect leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x49832d in malloc (/tmp/a.out+0x49832d)
#1 0x4c7f80 in fn /tmp/t.c:14:22
#2 0x4c7f71 in fn /tmp/t.c:12:5
#3 0x4c7f71 in fn /tmp/t.c:12:5
#4 0x4c7f71 in fn /tmp/t.c:12:5
#5 0x4c7f71 in fn /tmp/t.c:12:5
#6 0x4c7f71 in fn /tmp/t.c:12:5
#7 0x4c7f71 in fn /tmp/t.c:12:5
#8 0x4c7f71 in fn /tmp/t.c:12:5
#9 0x4c7f71 in fn /tmp/t.c:12:5
#10 0x4c7f71 in fn /tmp/t.c:12:5
#11 0x4c7f71 in fn /tmp/t.c:12:5
#12 0x4c8028 in main /tmp/t.c:23:3
#13 0x7f147d3a7d09 in __libc_start_main csu/../csu/libc-start.c:308:16
SUMMARY: AddressSanitizer: 16 byte(s) leaked in 2 allocation(s).
注:否
仅泄漏
一个。