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

2021-03-24 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93695

--- Comment #4 from David Malcolm  ---
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.

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

2021-03-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93695

--- Comment #3 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r11-7820-g71fc4655ab86ab66b40165b2cb49c1395ca82a9a
Author: David Malcolm 
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

2021-02-11 Thread dimhen at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93695

Dmitry G. Dyachenko  changed:

   What|Removed |Added

 CC||dimhen at gmail dot com

--- Comment #2 from Dmitry G. Dyachenko  ---
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

2020-02-12 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93695

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-12
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed; thanks.  Seems to happen at every optimization level, not just with
-O1.