This is an archive of the discontinued LLVM Phabricator instance.

[lsan] Respect default value of detect_leaks flag
AbandonedPublic

Authored by m.ostapenko on Feb 1 2017, 1:54 AM.

Details

Summary

When testing I noticed that ASan and LSan don't respect default value of detect_leaks flag, rewriting it by CAN_SANITIZE_LEAKS and true values in asan_init and lsan_init calls respectively. Let's change this since we would like to have LSan on by default on 64 bit arches and off on 32 bit ones.

Diff Detail

Repository
rL LLVM

Event Timeline

m.ostapenko created this revision.Feb 1 2017, 1:54 AM
eugenis edited edge metadata.Feb 1 2017, 12:02 PM

Why not change the flag default in sanitizer_flags.inc to CAN_SANITIZE_LEAKS?

kcc edited edge metadata.Feb 1 2017, 12:04 PM

since we would like to have LSan on by default on 64 bit arches and off on 32 bit ones.

Mmm. Do we? why not have it on by default even on 32-bit?
I remember that I was opposed to even enabling it at all on 32-bit, but if we enable it, let's make the default the same as on 64-bit, to avoid more confusion).
I assume that there are no false positives on 32-bit, only false negatives.

test/asan/TestCases/Linux/leak.cc
3

why?

In D29382#663755, @kcc wrote:

since we would like to have LSan on by default on 64 bit arches and off on 32 bit ones.

Mmm. Do we? why not have it on by default even on 32-bit?
I remember that I was opposed to even enabling it at all on 32-bit, but if we enable it, let's make the default the same as on 64-bit, to avoid more confusion).

Hm, OK, this is reasonable.

I assume that there are no false positives on 32-bit, only false negatives.

Yeah. The only thing I'm afraid of is Direct/Indirect leaks distinguishing (on 32 bit arches LSan may report false indirect leaks that are actually direct).
Anyway, I'm going to drop the patch.

test/asan/TestCases/Linux/leak.cc
3

Sad story. The value of 't' pointer is spilled to stack before calling printf. And for some reason LSan treats the top frame (that corresponds to main function) as a source of live pointers. This happens because SP value extracted via ptrace has lower value than the top address of main function frame.

ygribov added inline comments.Feb 2 2017, 9:09 AM
test/asan/TestCases/Linux/leak.cc
3

"for some reason" - just guesswork but maybe because atexit's frame happens to be there and keep the memory live for tracking pointers?

m.ostapenko abandoned this revision.Feb 3 2017, 4:00 AM

Abandon, let's have LSan enabled by default even for 32 bit arches.