public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug analyzer/99042] New: file-leak is wrong
@ 2021-02-09 18:54 antonio.chirizzi at gmail dot com
  2021-02-09 21:50 ` [Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call dmalcolm at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: antonio.chirizzi at gmail dot com @ 2021-02-09 18:54 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 99042
           Summary: file-leak is wrong
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: antonio.chirizzi at gmail dot com
  Target Milestone: ---

Created attachment 50155
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50155&action=edit
Reproducer log.c file for the bug

A file leak warning is shown, but it should not. See attached log.c reproducer.
Please note that I tried to strip the file to a minimum (while trying to leave
all the big complex data structures), but it still shows many warnings due to
undeclared functions (it's part of the git code base)
The leak warning is anyway consistent with what is shown on the real log.c file
in the code base.

In function ‘open_next_file’:
log.c:495:16: warning: leak of FILE ‘<unknown>’ [CWE-775]
[-Wanalyzer-file-leak]
  495 |         return 0;
      |                ^
  ‘open_next_file’: events 1-3
    |
    |  491 |         if ((rev->diffopt.file = fopen(filename.buf, "w")) ==
NULL)
    |      |            ^
    |      |            |
    |      |            (1) following ‘false’ branch...
    |......
    |  494 |         strbuf_release(&filename);
    |      |         ~~~~~~~~~~~~~~~~~~~~~~~~~
    |      |         |
    |      |         (2) ...to here
    |  495 |         return 0;
    |      |                ~
    |      |                |
    |      |                (3) ‘<unknown>’ leaks here
    |

Use "gcc -fanalyzer -c log.c"

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

* [Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call
  2021-02-09 18:54 [Bug analyzer/99042] New: file-leak is wrong antonio.chirizzi at gmail dot com
@ 2021-02-09 21:50 ` dmalcolm at gcc dot gnu.org
  2021-02-10  8:55 ` antonio.chirizzi at gmail dot com
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-09 21:50 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
            Summary|file-leak is wrong          |Another false
                   |                            |-Wanalyzer-malloc-leak on
                   |                            |code path involving unknown
                   |                            |function call
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-02-09

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks Antonio.

Confirmed with trunk.  A minimal reproducer:

$ cat ../../src/gcc/testsuite/gcc.dg/analyzer/pr99042.c
#include <stdio.h>

struct foo {
  FILE *file;
};

extern void unknown_fn ();

int open_next_file(struct foo *p)
{
  if ((p->file = fopen("test.txt", "w")) == NULL)
    return 1;
  unknown_fn ();
  return 0;
}




$ ./xgcc -B. -S ../../src/gcc/testsuite/gcc.dg/analyzer/pr99042.c -fanalyzer
In function ‘open_next_file’:
../../src/gcc/testsuite/gcc.dg/analyzer/pr99042.c:14:10: warning: leak of FILE
‘<unknown>’ [CWE-775] [-Wanalyzer-file-leak]
   14 |   return 0;
      |          ^
  ‘open_next_file’: events 1-5
    |
    |   11 |   if ((p->file = fopen("test.txt", "w")) == NULL)
    |      |      ~           ^~~~~~~~~~~~~~~~~~~~~~
    |      |      |           |
    |      |      |           (1) opened here
    |      |      (2) assuming ‘*p.file’ is non-NULL
    |      |      (3) following ‘false’ branch...
    |   12 |     return 1;
    |   13 |   unknown_fn ();
    |      |   ~~~~~~~~~~~~~   
    |      |   |
    |      |   (4) ...to here
    |   14 |   return 0;
    |      |          ~        
    |      |          |
    |      |          (5) ‘<unknown>’ leaks here; was opened at (1)
    |


The call to the unknown_fn seems to be necessary to trigger the false positive,
which is similar to PR analyzer/98575 (but not fixed by my recent patches for
that); updating Summary field accordingly.  In the git example, strbuf_release
is the unknown fn.

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

* [Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call
  2021-02-09 18:54 [Bug analyzer/99042] New: file-leak is wrong antonio.chirizzi at gmail dot com
  2021-02-09 21:50 ` [Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call dmalcolm at gcc dot gnu.org
@ 2021-02-10  8:55 ` antonio.chirizzi at gmail dot com
  2021-02-10 11:24 ` dmalcolm at gcc dot gnu.org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: antonio.chirizzi at gmail dot com @ 2021-02-10  8:55 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Antonio Chirizzi <antonio.chirizzi at gmail dot com> ---
Hi David,

just curious of what you mean with "unknown function". Is it something that has
not been declared or is not known to the compiler up to that point?

Thanks,

-Antonio

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

* [Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call
  2021-02-09 18:54 [Bug analyzer/99042] New: file-leak is wrong antonio.chirizzi at gmail dot com
  2021-02-09 21:50 ` [Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call dmalcolm at gcc dot gnu.org
  2021-02-10  8:55 ` antonio.chirizzi at gmail dot com
@ 2021-02-10 11:24 ` dmalcolm at gcc dot gnu.org
  2021-04-08 13:47 ` cvs-commit at gcc dot gnu.org
  2021-04-08 13:56 ` dmalcolm at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-10 11:24 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Antonio Chirizzi from comment #2)
> just curious of what you mean with "unknown function". Is it something that
> has not been declared or is not known to the compiler up to that point?

A function that the compiler doesn't have a definition for (typically a
function declared extern, defined in a different translation unit).

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

* [Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call
  2021-02-09 18:54 [Bug analyzer/99042] New: file-leak is wrong antonio.chirizzi at gmail dot com
                   ` (2 preceding siblings ...)
  2021-02-10 11:24 ` dmalcolm at gcc dot gnu.org
@ 2021-04-08 13:47 ` cvs-commit at gcc dot gnu.org
  2021-04-08 13:56 ` dmalcolm at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-08 13:47 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 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:3a66c289a3f395e50de79424e1e6f401a4dc1ab7

commit r11-8046-g3a66c289a3f395e50de79424e1e6f401a4dc1ab7
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Thu Apr 8 09:46:03 2021 -0400

    analyzer: fix leak false +ves due to maybe-clobbered regions
[PR99042,PR99774]

    Prior to this patch, program_state::detect_leaks worked by finding all
    live svalues in the old state and in the new state, and calling
    on_svalue_leak for each svalue that has changed from being live to
    not being live.

    PR analyzer/99042 and PR analyzer/99774 both describe false leak
    diagnostics from -fanalyzer (a false FILE * leak in git, and a false
    malloc leak in qemu, respectively).

    In both cases the root cause of the false leak diagnostic relates to
    svalues no longer being explicitly bound in the store due to regions
    being conservatively clobbered, due to an unknown function being
    called, or due to a write through a pointer that could alias the
    region, respectively.

    We have a transition from an svalue being explicitly live to not
    being explicitly live - but only because the store is being
    conservative, clobbering the binding.  The leak detection is looking
    for transitions from "definitely live" to "not definitely live",
    when it should be looking for transitions from "definitely live"
    to "definitely not live".

    This patch introduces a new class to temporarily capture information
    about svalues that were explicitly live, but for which a region bound
    to them got clobbered for conservative reasons.  This new
    "uncertainty_t" class is passed around to capture the data long enough
    for use in program_state::detect_leaks, where it is used to only
    complain about svalues that were definitely live and are now both
    not definitely live *or* possibly-live i.e. definitely not-live.

    The class also captures for which svalues we can't meaningfully track
    sm-state anymore, and resets the svalues back to the "start" state.

    Together, these changes fix the false leak reports.

    gcc/analyzer/ChangeLog:
            PR analyzer/99042
            PR analyzer/99774
            * engine.cc
            (impl_region_model_context::impl_region_model_context): Add
            uncertainty param and use it to initialize m_uncertainty.
            (impl_region_model_context::get_uncertainty): New.
            (impl_sm_context::get_fndecl_for_call): Add NULL for new
            uncertainty param when constructing impl_region_model_context.
            (impl_sm_context::get_state): Likewise.
            (impl_sm_context::set_next_state): Likewise.
            (impl_sm_context::warn): Likewise.
            (exploded_node::on_stmt): Add uncertainty param
            and use it when constructing impl_region_model_context.
            (exploded_node::on_edge): Add uncertainty param and pass
            to on_edge call.
            (exploded_node::detect_leaks): Create uncertainty_t and pass to
            impl_region_model_context.
            (exploded_graph::get_or_create_node): Create uncertainty_t and
            pass to prune_for_point.
            (maybe_process_run_of_before_supernode_enodes): Create
            uncertainty_t and pass to impl_region_model_context.
            (exploded_graph::process_node): Create uncertainty_t instances and
            pass around as needed.
            * exploded-graph.h
            (impl_region_model_context::impl_region_model_context): Add
            uncertainty param.
            (impl_region_model_context::get_uncertainty): New decl.
            (impl_region_model_context::m_uncertainty): New field.
            (exploded_node::on_stmt): Add uncertainty param.
            (exploded_node::on_edge): Likewise.
            * program-state.cc (sm_state_map::on_liveness_change): Get
            uncertainty from context and use it to unset sm-state from
            svalues as appropriate.
            (program_state::on_edge): Add uncertainty param and use it when
            constructing impl_region_model_context.  Fix indentation.
            (program_state::prune_for_point): Add uncertainty param and use it
            when constructing impl_region_model_context.
            (program_state::detect_leaks): Get any uncertainty from ctxt and
            use it to get maybe-live svalues for dest_state, rather than
            definitely-live ones; use this when determining which svalues
            have leaked.
            (selftest::test_program_state_merging): Create uncertainty_t and
            pass to impl_region_model_context.
            * program-state.h (program_state::on_edge): Add uncertainty param.
            (program_state::prune_for_point): Likewise.
            * region-model-impl-calls.cc (call_details::get_uncertainty): New.
            (region_model::impl_call_memcpy): Pass uncertainty to
            mark_region_as_unknown call.
            (region_model::impl_call_memset): Likewise.
            (region_model::impl_call_strcpy): Likewise.
            * region-model-reachability.cc (reachable_regions::handle_sval):
            Also add sval to m_mutable_svals.
            * region-model.cc (region_model::on_assignment): Pass any
            uncertainty from ctxt to the store::set_value call.
            (region_model::handle_unrecognized_call): Get any uncertainty from
            ctxt and use it to record mutable svalues at the unknown call.
            (region_model::get_reachable_svalues): Add uncertainty param and
            use it to mark any maybe-bound svalues as being reachable.
            (region_model::set_value): Pass any uncertainty from ctxt to the
            store::set_value call.
            (region_model::mark_region_as_unknown): Add uncertainty param and
            pass it on to the store::mark_region_as_unknown call.
            (region_model::update_for_call_summary): Add uncertainty param and
            pass it on to the region_model::mark_region_as_unknown call.
            * region-model.h (call_details::get_uncertainty): New decl.
            (region_model::get_reachable_svalues): Add uncertainty param.
            (region_model::mark_region_as_unknown): Add uncertainty param.
            (region_model_context::get_uncertainty): New vfunc.
            (noop_region_model_context::get_uncertainty): New vfunc
            implementation.
            * store.cc (dump_svalue_set): New.
            (uncertainty_t::dump_to_pp): New.
            (uncertainty_t::dump): New.
            (binding_cluster::clobber_region): Pass NULL for uncertainty to
            remove_overlapping_bindings.
            (binding_cluster::mark_region_as_unknown): Add uncertainty param
            and pass it to remove_overlapping_bindings.
            (binding_cluster::remove_overlapping_bindings): Add uncertainty
param.
            Use it to record any svalues that were in clobbered bindings.
            (store::set_value): Add uncertainty param.  Pass it to
            binding_cluster::mark_region_as_unknown when handling symbolic
            regions.
            (store::mark_region_as_unknown): Add uncertainty param and pass it
            to binding_cluster::mark_region_as_unknown.
            (store::remove_overlapping_bindings): Add uncertainty param and
            pass it to binding_cluster::remove_overlapping_bindings.
            * store.h (binding_cluster::mark_region_as_unknown): Add
            uncertainty param.
            (binding_cluster::remove_overlapping_bindings): Likewise.
            (store::set_value): Likewise.
            (store::mark_region_as_unknown): Likewise.

    gcc/testsuite/ChangeLog:
            PR analyzer/99042
            PR analyzer/99774
            * gcc.dg/analyzer/pr99042.c: New test.
            * gcc.dg/analyzer/pr99774-1.c: New test.
            * gcc.dg/analyzer/pr99774-2.c: New test.

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

* [Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call
  2021-02-09 18:54 [Bug analyzer/99042] New: file-leak is wrong antonio.chirizzi at gmail dot com
                   ` (3 preceding siblings ...)
  2021-04-08 13:47 ` cvs-commit at gcc dot gnu.org
@ 2021-04-08 13:56 ` dmalcolm at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-04-08 13:56 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #5 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Should be fixed by the above patch

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

end of thread, other threads:[~2021-04-08 13:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-09 18:54 [Bug analyzer/99042] New: file-leak is wrong antonio.chirizzi at gmail dot com
2021-02-09 21:50 ` [Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call dmalcolm at gcc dot gnu.org
2021-02-10  8:55 ` antonio.chirizzi at gmail dot com
2021-02-10 11:24 ` dmalcolm at gcc dot gnu.org
2021-04-08 13:47 ` cvs-commit at gcc dot gnu.org
2021-04-08 13:56 ` 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).