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/104560] False positive from -Wanalyzer-free-of-non-heap seen with rdma-core Date: Wed, 16 Feb 2022 23:49:33 +0000 [thread overview] Message-ID: <bug-104560-4-AWTb0Zp53P@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-104560-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104560 --- Comment #1 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:a61aaee63848d422e8443e17bbec3257ee59d5d8 commit r12-7268-ga61aaee63848d422e8443e17bbec3257ee59d5d8 Author: David Malcolm <dmalcolm@redhat.com> Date: Wed Feb 16 09:06:46 2022 -0500 analyzer: fixes to free of non-heap detection [PR104560] PR analyzer/104560 reports various false positives from -Wanalyzer-free-of-non-heap seen with rdma-core, on what's effectively: free (&ptr->field) where in this case "field" is the first element of its struct, and thus &ptr->field == ptr, and could be on the heap. The root cause is due to malloc_state_machine::on_stmt making "LHS = &EXPR;" transition LHS from start to non_heap when EXPR is not a MEM_REF; this assumption doesn't hold for the above case. This patch eliminates that state transition, instead relying on malloc_state_machine::get_default_state to detect regions known to not be on the heap. Doing so fixes the false positive, but eliminates some events relating to free-of-alloca identifying the alloca, so the patch also reworks free_of_non_heap to capture which region has been freed, adding region creation events to diagnostic paths, so that the alloca calls can be identified, and using the memory space of the region for more precise wording of the diagnostic. The improvement to malloc_state_machine::get_default_state also means we now detect attempts to free VLAs, functions and code labels. In doing so I spotted that I wasn't adding region creation events for regions for global variables, and for cases where an allocation is the last stmt within its basic block, so the patch also fixes these issues. gcc/analyzer/ChangeLog: PR analyzer/104560 * diagnostic-manager.cc (diagnostic_manager::build_emission_path): Add region creation events for globals of interest. (null_assignment_sm_context::get_old_program_state): New. (diagnostic_manager::add_events_for_eedge): Move check for changing dynamic extents from PK_BEFORE_STMT case to after the switch on the dst_point's kind so that we can emit them for the final stmt in a basic block. * engine.cc (impl_sm_context::get_old_program_state): New. * sm-malloc.cc (malloc_state_machine::get_default_state): Rewrite detection of m_non_heap to use get_memory_space. (free_of_non_heap::free_of_non_heap): Add freed_reg param. (free_of_non_heap::subclass_equal_p): Update for changes to fields. (free_of_non_heap::emit): Drop m_kind in favor of get_memory_space. (free_of_non_heap::describe_state_change): Remove logic for detecting alloca. (free_of_non_heap::mark_interesting_stuff): Add region-creation of m_freed_reg. (free_of_non_heap::get_memory_space): New. (free_of_non_heap::kind): Drop enum. (free_of_non_heap::m_freed_reg): New field. (free_of_non_heap::m_kind): Drop field. (malloc_state_machine::on_stmt): Drop transition to m_non_heap. (malloc_state_machine::handle_free_of_non_heap): New function, split out from on_deallocator_call and on_realloc_call, adding detection of the freed region. (malloc_state_machine::on_deallocator_call): Use it. (malloc_state_machine::on_realloc_call): Likewise. * sm.h (sm_context::get_old_program_state): New vfunc. gcc/testsuite/ChangeLog: PR analyzer/104560 * g++.dg/analyzer/placement-new.C: Update expected wording. * g++.dg/analyzer/pr100244.C: Likewise. * gcc.dg/analyzer/attr-malloc-1.c (test_7): Likewise. * gcc.dg/analyzer/malloc-1.c (test_24): Likewise. (test_25): Likewise. (test_26): Likewise. (test_50a, test_50b, test_50c): New. * gcc.dg/analyzer/malloc-callbacks.c (test_5): Update expected wording. * gcc.dg/analyzer/malloc-paths-8.c: Likewise. * gcc.dg/analyzer/pr104560-1.c: New test. * gcc.dg/analyzer/pr104560-2.c: New test. * gcc.dg/analyzer/realloc-1.c (test_7): Updated expected wording. * gcc.dg/analyzer/vla-1.c (test_2): New. Prune output from -Wfree-nonheap-object. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
next prev parent reply other threads:[~2022-02-16 23:49 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-15 22:34 [Bug analyzer/104560] New: " dmalcolm at gcc dot gnu.org 2022-02-16 23:49 ` cvs-commit at gcc dot gnu.org [this message] 2022-02-16 23:58 ` [Bug analyzer/104560] " 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-104560-4-AWTb0Zp53P@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: linkBe 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).