[cfe-dev] [StaticAnalyzer] How to suppress bug reports when a checker reached a noreturn function

Haowei Wu via cfe-dev cfe-dev at lists.llvm.org
Mon Jul 31 10:51:29 PDT 2017


Hi,

I am working on a checker and I would like to suppress bug reports when a
path reached a function with [[noreturn]] attribute. For example:

typedef uint32_t mx_handle_t;
typedef int32_t mx_status_t;

mx_status_t mx_channel_create(
uint32_t options,
mx_handle_t* out0,
mx_handle_t* out1);

[[noreturn]] void noreturnFunc();

void checkNoReturn() {
  mx_handle_t sa, sb;
  mx_channel_create(0, &sa, &sb);
  //...
  noreturnFunc();
}

Function mx_channel_create will allocate two handles(file descriptors) and
save them to 'sa' and 'sb'. Since there is no other call to release these
two handles, the checker will report them as leaked. But in this special
case, there is a call to 'noreturnFunc()' which will terminate the process
and leaked handles will be recycled by the OS so it is may not necessary to
report these bugs. The source code of the checker can be found
in D35968, D36022, D36023, D36024.

My first thought is that I can use REGISTER_TRAIT_WITHPROGRAMSTATE macro to
add a bool flag in the ProgramState and this flag will be set if the
FunctionDecl->isNoReturn() returns true in the evalCall callback. Then in
the checkDeadSymbols callback, do not report any leaked symbols if the flag
registered through REGISTER_TRAIT_WITHPROGRAMSTATE is set. However, I did
some experiment and found out that in the code example, the symbols in 'sa'
and 'sb' were dead in the checkDeadSymbols before the evalCall on '
noreturnFunc' was invoked. Further experiment showed that the
checkDeadSymbols on 'sa' and 'sb' was invoked even before checkPreStmt(const
CallExpr *, CheckerContext &) callback. So this solution does not work.

Is there anything I can do in the checker to solve this problem?

Thanks for any help.

Haowei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170731/8acbef19/attachment.html>


More information about the cfe-dev mailing list