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
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). |
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)? |
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. |
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. |
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.
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).