public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug analyzer/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)
Date: Fri, 12 Feb 2021 01:32:42 +0000	[thread overview]
Message-ID: <bug-98969-4-bRRDMKaZe0@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-98969-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #10 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:467a48205279cab368dbeb02879bbbbe4b721516

commit r11-7202-g467a48205279cab368dbeb02879bbbbe4b721516
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Thu Feb 11 20:31:28 2021 -0500

    analyzer: fix ICE in print_mem_ref [PR98969]

    PR analyzer/98969 and PR analyzer/99064 describes ICEs, in both cases
    within print_mem_ref, when falsely reporting memory leaks - though it
    is possible to generate the ICE on other diagnostics (which I added
    in one of the test cases).

    This patch fixes the ICE, leaving the fix for the leak false positives
    as followup work.

    The analyzer uses region_model::get_representative_path_var and
    region_model::get_representative_tree to map back from its svalue
    and region classes to the tree type used by the rest of the compiler,
    and, in particular, for diagnostics.

    The root cause of the ICE is sloppiness about types within those
    functions; specifically when casts were stripped off svalues.  To
    track these down I added wrapper functions that verify that the
    types of the results are correct, and in doing so found various
    other type-safety issues, which the patch also fixes.

    Doing so led to various changes in diagnostics messages due to
    more accurate types, but I felt that these changes weren't
    desirable.
    For example, the warning at CVE-2005-1689-minimal.c line 48
    which expects:
      double-'free' of 'inbuf.data'
    changed fo
      double-'free' of '(char *)inbuf.data'

    So I added stripping of top-level casts where necessary to avoid
    cluttering diagnostics.

    Finally, the more accurate types led to worse results from
    readability_comparator, where e.g. the event message at line 50
    of sensitive-1.c regressed from the precise:
      passing sensitive value 'password' in call to 'called_by_test_5' from
'test_5'
    to the vaguer:
      calling 'called_by_test_5' from 'test_5'
    This was due to erroneously picking the initial value of "password"
    in the caller frame as the best value within the *callee* frame, due to
    "char *" vs "const char *", which confuses the logic for tracking values
    that pass along callgraph edges.  The patch fixes this by combining the
    readability tests for tree and stack depth, rather than performing
    them in sequence, so that it favors the value in the deepest frame.

    As noted above, the patch fixes the ICEs, but does not fix the
    leak false positives.

    gcc/analyzer/ChangeLog:
            PR analyzer/98969
            * engine.cc (readability): Add names for the various arbitrary
            values.  Handle NOP_EXPR and INTEGER_CST.
            (readability_comparator): Combine the readability tests for
            tree and stack depth, rather than performing them sequentially.
            (impl_region_model_context::on_state_leak): Strip off top-level
            casts.
            * region-model.cc (region_model::get_representative_path_var): Add
            type-checking, moving the bulk of the implementation to...
            (region_model::get_representative_path_var_1): ...here.  Respect
            types in casts by recursing and re-adding the cast, rather than
            merely stripping them off.  Use the correct type when handling
            region_svalue.
            (region_model::get_representative_tree): Strip off any top-level
            cast.
            (region_model::get_representative_path_var): Add type-checking,
            moving the bulk of the implementation to...
            (region_model::get_representative_path_var_1): ...here.
            * region-model.h (region_model::get_representative_path_var_1):
            New decl
            (region_model::get_representative_path_var_1): New decl.
            * store.cc (append_pathvar_with_type): New.
            (binding_cluster::get_representative_path_vars): Cast path_vars
            to the correct type when adding them to *OUT_PVS.

    gcc/testsuite/ChangeLog:
            PR analyzer/98969
            * g++.dg/analyzer/pr99064.C: New test.
            * gcc.dg/analyzer/pr98969.c: New test.

  parent reply	other threads:[~2021-02-12  1:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04 17:06 [Bug c/98969] New: " asolokha at gmx dot com
2021-02-04 20:34 ` [Bug c/98969] " msebor at gcc dot gnu.org
2021-02-04 20:50 ` msebor at gcc dot gnu.org
2021-02-04 20:52 ` jakub at gcc dot gnu.org
2021-02-05  8:15 ` [Bug analyzer/98969] " rguenth at gcc dot gnu.org
2021-02-05 14:08 ` jakub at gcc dot gnu.org
2021-02-05 14:18 ` dmalcolm at gcc dot gnu.org
2021-02-06 16:16 ` msebor at gcc dot gnu.org
2021-02-06 17:10 ` msebor at gcc dot gnu.org
2021-02-11  1:59 ` dmalcolm at gcc dot gnu.org
2021-02-12  1:32 ` cvs-commit at gcc dot gnu.org [this message]
2021-02-12  1:36 ` dmalcolm at gcc dot gnu.org
2021-02-17 15:38 ` cvs-commit at gcc dot gnu.org
2021-02-17 15:40 ` dmalcolm at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-98969-4-bRRDMKaZe0@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).