* [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