public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dmalcolm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug analyzer/102308] False positive -Wanalyzer-malloc-leak when writing to array in struct
Date: Thu, 07 Apr 2022 12:47:18 +0000	[thread overview]
Message-ID: <bug-102308-4-DOnJl6WOZg@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-102308-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
I typoed this bug's ID 102308 as 102208 in the commit message; so the message
went to the wrong bug; here's a copy-and-paste of the commit notification that
went there:

The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>:

https://gcc.gnu.org/g:88b939b19ab454ab2d932ef292bbc557abe4431c

commit r12-8047-g88b939b19ab454ab2d932ef292bbc557abe4431c
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Thu Apr 7 08:33:26 2022 -0400

    analyzer: fix leak false +ve with symbolic writes [PR102208]

    PR analyzer/102208 reports false positives from -Wanalyzer-malloc-leak.
    The root cause is the analyzer getting confused about symbolic writes
    that could alias a pointer referencing a malloced buffer.

    struct st
    {
      void *ptr;
      int arr[10];
    };

    struct st test (int idx)
    {
      struct st s;
      s.ptr = __builtin_malloc (1024);  /* (1) */
      s.arr[idx] = 42;                  /* (2) */
      return s;
    }

    When removing overlapping bindings at (2),
    store::remove_overlapping_bindings was failing to pass on the
    uncertainty_t *, and thus when clobbering the binding of s.ptr, the
    heap-allocated pointer was not being added to the set of maybe-bound
    svalues, and thus being treated as leaking.

    This patch fixes this, so that s.ptr from (1) is treated as maybe-bound
    after the write at (2), fixing the leak false postive.

    Doing so requires the store to be smarter about how clobbering happens
    with various combinations of concrete keys and symbolic keys within
    concrete clusters and symbolic clusters, so that we don't lose warnings
    about definite leaks.

    gcc/analyzer/ChangeLog:
            PR analyzer/102208
            * store.cc (binding_map::remove_overlapping_bindings): Add
            "always_overlap" param, using it to generalize to the case where
            we want to remove all bindings.  Update "uncertainty" logic to
            only record maybe-bound values for cases where there is a symbolic
            write involved.
            (binding_cluster::mark_region_as_unknown): Split param "reg" into
            "reg_to_bind" and "reg_for_overlap".
            (binding_cluster::maybe_get_compound_binding): Pass "false" to
            binding_map::remove_overlapping_bindings new "always_overlap"
param.
            (binding_cluster::remove_overlapping_bindings): Determine
            "always_overlap" and pass it to
            binding_map::remove_overlapping_bindings.
            (store::set_value): Pass uncertainty to remove_overlapping_bindings
            call.  Update for new param of
            binding_cluster::mark_region_as_unknown, passing both the base
            region of the iter_cluster, and the lhs_reg.
            (store::mark_region_as_unknown): Update for new param of
            binding_cluster::mark_region_as_unknown, passing "reg" for both.
            (store::remove_overlapping_bindings): Add param "uncertainty", and
            pass it on to call to
            binding_cluster::remove_overlapping_bindings.
            * store.h (binding_map::remove_overlapping_bindings): Add
            "always_overlap" param.
            (binding_cluster::mark_region_as_unknown): Split param "reg" into
            "reg_to_bind" and "reg_for_overlap".
            (store::remove_overlapping_bindings): Add param "uncertainty".

    gcc/testsuite/ChangeLog:
            PR analyzer/102208
            * gcc.dg/analyzer/symbolic-9.c: New test.
            * gcc.dg/analyzer/torture/leak-pr102308-1.c: New test.
            * gcc.dg/analyzer/torture/leak-pr102308-2.c: New test.

    Signed-off-by: David Malcolm <dmalcolm@redhat.com>

  parent reply	other threads:[~2022-04-07 12:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-13 14:39 [Bug analyzer/102308] New: " matti.niemenmaa+gccbugs at iki dot fi
2022-04-06 22:30 ` [Bug analyzer/102308] " dmalcolm at gcc dot gnu.org
2022-04-07 12:47 ` dmalcolm at gcc dot gnu.org [this message]
2022-04-07 12:47 ` 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-102308-4-DOnJl6WOZg@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).