This is an archive of the discontinued LLVM Phabricator instance.

[test] Enable LeakSanitizer on 64-bit Darwin ASan clang builds
ClosedPublic

Authored by fjricci on Sep 13 2017, 7:08 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

fjricci created this revision.Sep 13 2017, 7:08 AM
Hahnfeld edited edge metadata.Sep 21 2017, 1:40 PM

@gtbercea and I will take a look at the leak in D34784 next week and hopefully get it sorted out...

fjricci updated this revision to Diff 116871.Sep 27 2017, 1:24 PM
fjricci edited the summary of this revision. (Show Details)

Remove disabled openmp test, since the leak was fixed in r314328

fjricci added a reviewer: vsk.Sep 27 2017, 1:33 PM
Hahnfeld resigned from this revision.Sep 27 2017, 1:36 PM

Resigning as this isn't related to OpenMP anymore

vsk edited edge metadata.Sep 27 2017, 4:04 PM
vsk added a subscriber: gottesmm.

I'm inclined to just accept this because it looks simple and harmless. Just to be sure, could you point me to any explanation of why LSan is disabled on Darwin in the first place? CC'ing @gottesmm, since he's looked at using LSan on Darwin before.

@kubamracek and I had a discussion about this here: https://reviews.llvm.org/D35443

I think the issue boils down to complexities in objective-C and swift code, and their associated system libraries. LeakSanitizer works well on C++ code (as evidenced by the lack of false positives in the llvm and clang test suites), but I don't personally have the bandwidth to ensure the same goes for objective-C and swift code, particularly due to the fact that many objective-C system APIs are opaque and tough to deal with as someone without access to the source code (stashing pointers in mmap'd pages etc).

LeakSanitizer for Darwin is also fairly new (I finished the implementation within the last couple months), which is why this hasn't been considered before.

There's also a performance/value consideration, LeakSanitizer doesn't impact performance significantly (and has about the same impact on Darwin as it does on Linux), but it still does come with some overhead, and it seems reasonable to allow ASan users to decide whether or not it's a feature they'd like to use.

vsk accepted this revision.Sep 28 2017, 1:37 PM

LGTM, thanks for the pointer.

This revision is now accepted and ready to land.Sep 28 2017, 1:37 PM

Looks like the sanitizer configuration is all handled in the top-level llvm lit configuration now, so I'll just merge the crash-vfs-ivfsoverlay.m part of this change, in conjunction with D37781.

This revision was automatically updated to reflect the committed changes.