This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Add "create_sink" annotation support to MagentaHandleChecker
AbandonedPublic

Authored by haowei on Aug 8 2017, 10:35 AM.

Details

Reviewers
NoQ
dcoughlin
Summary

This patch adds "mx_create_sink" annotation support to MagentaHandleChecker to address the false positives found in Magenta unit tests. After this patch, when a call to a function contains this annotation, MagentaHandleChecker will create a sink node which will suppress the handle leaks warnings if the leak is post-dominated by this function (similar to a noreturn function).

The target problem it tries to solve can be illustrated in following example:

static bool handle_info_test(void) {
    BEGIN_TEST;

    mx_handle_t event;
    ASSERT_EQ(mx_event_create(0u, &event), 0, "");
    mx_handle_t duped;
    mx_status_t status = mx_handle_duplicate(event, MX_RIGHT_SAME_RIGHTS, &duped);
    ASSERT_EQ(status, MX_OK, "");
    // ....
}

Unlike the "assert" keyword in C++, the ASSERT_EQ macro will not terminate the execution of the unit test program (in other words, it will not invoke a noreturn function), instead it will return false and the error will be recorded by the unit test runner. Therefore, before this patch, the MagentaHandleChecker will report handle leaks on these assertion failures as the function reaches return and symbol that contains the acquired handles are acquired. These reports are not helpful as assertion failures in unit tests mean test failures. With the help of this patch, we add a call to a function with "mx_create_sink" annotation in the failure branch in definition "ASSERT_EQ". In this case, the MagentaHandleChecker will create a sink node in each assertion failure and suppress the warnings if the leaks are post-dominated by assertion failures.

Diff Detail

Event Timeline

haowei created this revision.Aug 8 2017, 10:35 AM
dcoughlin edited edge metadata.Sep 5 2017, 10:31 AM

I'm a bit surprised that this is needed for unit tests. Aren't unit tests supposed to clean up their own state? Leaking a scarce resource in one unit test can cause another unit test to fail, which can be hard to track down. Or is this for deliberately testing a scenario where a resource is leaked? If you're deliberately testing a leaking scenario, it seems to me that using #ifndef clang_analyzer would probably be an easier suppression mechanism for the test author to understand and maintain.

Can you elaborate on why you're running the analyzer on units tests and how reports from the analyzer on unit tests are used? I think it would be helpful for us to understand your work flow.

Also, in general, my feeling is the exposing the internal mechanisms of the analyzer (here, the notion of a sink) in an attribute is not good for users. Ideally, attributes should be used to describe the behavior of code that they annotate. This means that they also serve as documentation for the user and not just as an ad hoc mechanism to communicate with 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.