From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 489943835416; Fri, 5 Mar 2021 23:54:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 489943835416 From: "dmalcolm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug analyzer/93355] Missing diagnostic for missing fclose in intl/localealias.c Date: Fri, 05 Mar 2021 23:54:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: analyzer X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dmalcolm at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: dmalcolm at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 23:54:14 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D93355 --- Comment #9 from David Malcolm --- Going back to the summary from comment #4: (a) It happens to successfully explore enough of the graph to find the leak, but hits complexity limits at a program point (b) Without -fno-analyzer-feasibility, it falsely rejects the path as infeasible (c) is effectively fixed by r11-7029-g8a2750086d57d1a2251d9239fa4e6c2dc9ec3= a86. The issue with (a) is that we have a non-trivial function calling a non-tri= vial function, and the lack of call summaries means that we get a state explosion due to expanding the callee 3 times (once directly, and twice at the single callsite, exploded in the callee). The callee has an issue that is found standalone (since r11-7029-g8a2750086d57d1a2251d9239fa4e6c2dc9ec3a86). Hen= ce the state explosion on nested calls means that we won't fail to find the standalone issue. So although it would be good to fix the state explosion/= call summary issue, I think it's lower priority than fixing the feasibility issu= e.=20 (I spent some time this week looking at call summaries, but now think this = is lower priority than the feasibility issue). For (b), I've tried several approaches, but now that we're trying multiple paths per dedupe candidate, it's hard to see where things go wrong. I've b= een experimenting with better ways to visualize this to try to make debugging it less painful.=