[Bug analyzer/93695] Allocation and freeing memory for array members in loops is not handled properly by the analyzer

[Bug analyzer/93695] Allocation and freeing memory for array members in loops is not handled properly by the analyzer

[dimhen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93695

Dmitry G. Dyachenko <dimhen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dimhen at gmail dot com

--- Comment #2 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
gcc version 11.0.0 20210210 (experimental) [master revision
bd0e37f68a3:deed5164277:72932511053596091ad291539022b51d9f2ba418]

PASS for me

[Bug analyzer/93695] Allocation and freeing memory for array members in loops is not handled properly by the analyzer

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93695

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>:

https://gcc.gnu.org/g:71fc4655ab86ab66b40165b2cb49c1395ca82a9a

commit r11-7820-g71fc4655ab86ab66b40165b2cb49c1395ca82a9a
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Wed Mar 24 20:47:57 2021 -0400

    analyzer; reset sm-state for SSA names at def-stmts
[PR93695,PR99044,PR99716]

    Various false positives from -fanalyzer involve SSA names in loops,
    where sm-state associated with an SSA name from one iteration is
    erroneously reused in a subsequent iteration.

    For example, PR analyzer/99716 describes a false
      "double 'fclose' of FILE 'fp'"
    on:

      for (i = 0; i < 2; ++i) {
        FILE *fp = fopen ("/tmp/test", "w");
        fprintf (fp, "hello");
        fclose (fp);
      }

    where the gimple of the loop body is:

      fp_7 = fopen ("/tmp/test", "w");
      __builtin_fwrite ("hello", 1, 5, fp_7);
      fclose (fp_7);
      i_10 = i_1 + 1;

    where fp_7 transitions to "closed" at the fclose, but is not
    reset at the subsequent fopen, leading to the false positive
    when the fclose is re-reached.

    The fix is to reset sm-state for svalues that involve an SSA name
    at the SSA name's def-stmt, since the def-stmt effectively changes
    the meaning of those related svalues.

    gcc/analyzer/ChangeLog:
            PR analyzer/93695
            PR analyzer/99044
            PR analyzer/99716
            * engine.cc (exploded_node::on_stmt): Clear sm-state involving
            an SSA name at the def-stmt of that SSA name.
            * program-state.cc (sm_state_map::purge_state_involving): New.
            * program-state.h (sm_state_map::purge_state_involving): New decl.
            * region-model.cc (selftest::test_involves_p): New.
            (selftest::analyzer_region_model_cc_tests): Call it.
            * svalue.cc (class involvement_visitor): New class
            (svalue::involves_p): New.
            * svalue.h (svalue::involves_p): New decl.

    gcc/testsuite/ChangeLog:
            PR analyzer/93695
            PR analyzer/99044
            PR analyzer/99716
            * gcc.dg/analyzer/attr-malloc-CVE-2019-19078-usb-leak.c: Remove
            xfail.
            * gcc.dg/analyzer/pr93695-1.c: New test.
            * gcc.dg/analyzer/pr99044-1.c: New test.
            * gcc.dg/analyzer/pr99044-2.c: New test.
            * gcc.dg/analyzer/pr99716-1.c: New test.
            * gcc.dg/analyzer/pr99716-2.c: New test.
            * gcc.dg/analyzer/pr99716-3.c: New test.

[Bug analyzer/93695] Allocation and freeing memory for array members in loops is not handled properly by the analyzer

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93695

--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
The above commit helps with related issues, but doesn't yet fix this bug.

In particular, -Wanalyzer-too-complex shows that the analyzer generates an
infinite chain of states for the loop, and eventually hits a safety limit,
which I believe prevents analyzing anything after the loop.  See
gcc.dg/analyzer/pr93695-1.c in the above patch for examples.