This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Suppress warning when bug path contains noreturn function or return from main in MagentaHandleChecker
AbandonedPublic

Authored by haowei on Aug 2 2017, 4:41 PM.

Details

Reviewers
NoQ
dcoughlin
Summary

This patch will suppress handle leak warnings if the path of a bug reported by MagentaHandleChecker will reach a no return function or will reach the end of main function. As these two scenarios mean program crash and the leaked handle will be recycled by OS, there is no point to report these bugs.

Diff Detail

Event Timeline

haowei created this revision.Aug 2 2017, 4:41 PM
NoQ added inline comments.Aug 10 2017, 12:32 AM
lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
483–498

I think the analyzer core should do this. This code already has a global effect on the analysis - it's enough for one checker to generate the sink. Additionally, there's also the CFG-based variant of suppress-on-sink, which would need to be extended to support this as well - this other variant kicks in when the analysis was interrupted before reaching the sink (see D35673 and D35674).

xazax.hun added inline comments.Aug 10 2017, 1:58 AM
lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
483–498

Do we want to do this unconditionally? Are all of the resources cleaned up on all of the supported OSes, or maybe for some leak issues it still makes sense to warn in these cases? Or we simply favor false negatives over false positives in this case (might make sense)?

NoQ added inline comments.Aug 10 2017, 2:55 AM
lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
483–498

We could add a flag to setSuppressOnSink() as an orthogonal change if it turns out that we need it; i'm not aware of any stuff that badly needs to be cleaned up before normal program termination in the existing checkers.

haowei added inline comments.Aug 10 2017, 9:55 AM
lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp
483–498

I also think this should be done in a separate checker like NoReturnFunctionChecker or within the analyzer as some other resource leak checkers might need this. I am also thinking D36475 should be in a separate checker as well. That annotation support really helps us a lot in analyzing unit test code and it might be useful for others if someone run into similar situation like us. But I cannot decide if we should use the annotate attribute or define a new attribute just for the analyzer.

dcoughlin edited edge metadata.Sep 5 2017, 10:30 AM

I'm worried about doing this for main(). I think many people would find it surprising if analyzing main() were to behave differently than other functions. I'm particularly worried because I think it is quite common to create a small test program with only main() to understand the behavior of the analyzer.

haowei abandoned this revision.Jan 5 2021, 3:53 PM

An updated version was landed in f4c26d993bdc . This diff is no longer needed.