public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug analyzer/102308] New: False positive -Wanalyzer-malloc-leak when writing to array in struct
@ 2021-09-13 14:39 matti.niemenmaa+gccbugs at iki dot fi
  2022-04-06 22:30 ` [Bug analyzer/102308] " dmalcolm at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: matti.niemenmaa+gccbugs at iki dot fi @ 2021-09-13 14:39 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 102308
           Summary: False positive -Wanalyzer-malloc-leak when writing to
                    array in struct
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: matti.niemenmaa+gccbugs at iki dot fi
  Target Milestone: ---

The following code:


$ cat bug.c
#include <stdlib.h>

struct s {
  char *p;
  int arr[2];
};

int main(void) {
  struct s *s = malloc(sizeof *s);
  if (s) {
    s->p = malloc(1);
    for (int i = 0; i < 2; i++)
      s->arr[i] = -1;
  }
  if (s) {
    free(s->p);
    free(s);
  }
}


Triggers -Wanalyzer-malloc-leak of "<unknown>" (apparently the malloc(1)) in
the loop that writes to the array:


$ gcc --version | head -1
gcc (GCC) 11.1.0
$ gcc -fanalyzer -O2 -c -o /dev/null bug.c
bug.c: In function ‘main’:
bug.c:11:17: warning: leak of ‘<unknown>’ [CWE-401] [-Wanalyzer-malloc-leak]
   11 |       s->arr[i] = -1;
      |       ~~~~~~~~~~^~~~
  ‘main’: events 1-8
    |
    |    8 |   if (s) {
    |      |      ^
    |      |      |
    |      |      (1) following ‘true’ branch (when ‘s’ is non-NULL)...
    |    9 |     s->p = malloc(1);
    |      |            ~~~~~~~~~
    |      |            |
    |      |            (2) ...to here
    |      |            (3) allocated here
    |   10 |     for (int i = 0; i < 2; i++)
    |      |                     ~~~~~
    |      |                       |
    |      |                       (4) following ‘true’ branch (when ‘i !=
2’)...
    |      |                       (6) following ‘true’ branch (when ‘i !=
2’)...
    |   11 |       s->arr[i] = -1;
    |      |       ~~~~~~~~~~~~~~
    |      |                 |
    |      |                 (5) ...to here
    |      |                 (7) ...to here
    |      |                 (8) ‘<unknown>’ leaks here; was allocated at (3)


Even though there's evidently no leak.

As shown, the above triggers even on -O2. With -O0 the example can be
simplified a bit:


#include <stdlib.h>
struct s {
  char *p;
  int arr[1];
};
int main(void) {
  struct s s;
  s.p = malloc(1);
  for (int i = 0; i < 1; i++)
    s.arr[i] = -1;
  free(s.p);
}


Here the same type of leak is reported on -O0, but not -O2.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug analyzer/102308] False positive -Wanalyzer-malloc-leak when writing to array in struct
  2021-09-13 14:39 [Bug analyzer/102308] New: False positive -Wanalyzer-malloc-leak when writing to array in struct matti.niemenmaa+gccbugs at iki dot fi
@ 2022-04-06 22:30 ` dmalcolm at gcc dot gnu.org
  2022-04-07 12:47 ` dmalcolm at gcc dot gnu.org
  2022-04-07 12:47 ` dmalcolm at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-04-06 22:30 UTC (permalink / raw)
  To: gcc-bugs

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-04-06
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks for filing this bug report.  I'm testing a fix.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug analyzer/102308] False positive -Wanalyzer-malloc-leak when writing to array in struct
  2021-09-13 14:39 [Bug analyzer/102308] New: False positive -Wanalyzer-malloc-leak when writing to array in struct 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
  2022-04-07 12:47 ` dmalcolm at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-04-07 12:47 UTC (permalink / raw)
  To: gcc-bugs

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>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug analyzer/102308] False positive -Wanalyzer-malloc-leak when writing to array in struct
  2021-09-13 14:39 [Bug analyzer/102308] New: False positive -Wanalyzer-malloc-leak when writing to array in struct 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
@ 2022-04-07 12:47 ` dmalcolm at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-04-07 12:47 UTC (permalink / raw)
  To: gcc-bugs

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Should be fixed by the above commit for GCC 12.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-04-07 12:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-13 14:39 [Bug analyzer/102308] New: False positive -Wanalyzer-malloc-leak when writing to array in struct 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
2022-04-07 12:47 ` dmalcolm at gcc dot gnu.org

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).