* [Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495
2021-01-06 19:54 [Bug testsuite/98575] New: [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495 seurer at gcc dot gnu.org
@ 2021-01-07 8:27 ` rguenth at gcc dot gnu.org
2021-02-04 19:38 ` dmalcolm at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-07 8:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.0
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495
2021-01-06 19:54 [Bug testsuite/98575] New: [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495 seurer at gcc dot gnu.org
2021-01-07 8:27 ` [Bug analyzer/98575] " rguenth at gcc dot gnu.org
@ 2021-02-04 19:38 ` dmalcolm at gcc dot gnu.org
2021-02-04 23:02 ` dmalcolm at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-04 19:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-02-04
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Confirmed; I can reproduce it on gcc135 in the compile farm (todays' trunk,
with powerpc64le-unknown-linux-gnu)
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495
2021-01-06 19:54 [Bug testsuite/98575] New: [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495 seurer at gcc dot gnu.org
2021-01-07 8:27 ` [Bug analyzer/98575] " rguenth at gcc dot gnu.org
2021-02-04 19:38 ` dmalcolm at gcc dot gnu.org
@ 2021-02-04 23:02 ` dmalcolm at gcc dot gnu.org
2021-02-04 23:16 ` dmalcolm at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-04 23:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
This turns out to be due to differences in the inline implementation of getchar
in <stdio.h> which expose a latent bug in leak-detection.
On my x86_64 Fedora 32 box,
/usr/include/bits/stdio.h is from glibc-headers-2.31-2.fc32.x86_64 and has:
/* Read a character from stdin. */
__STDIO_INLINE int
getchar (void)
{
return getc (stdin);
}
On gcc135 in the GCC compile farm,
/usr/include/bits/stdio.h is from glibc-headers-2.17-307.el7.1.ppc64le and has:
/* Read a character from stdin. */
__STDIO_INLINE int
getchar (void)
{
return _IO_getc (stdin);
}
The analyzer's sm-file.cc "knows" about "getc" and thus the analyzer treats
getc as having no side-effects.
In contrast, it doesn't "know" about "_IO_getc" and thus treats it as
potentially clobbering curbp, which exposes a latent false-positive bug in leak
detection.
The reported leak seems like a bug where the analyzer doesn't seem to grok that
a pointer written through a clobbered global variable is still live if that
global variable hasn't been clobbered again. A minimal reproducer for this is:
void **g;
extern void unknown_fn (void);
int test(void)
{
void *p;
#ifdef CALL_UNKNOWN
unknown_fn ();
#endif
p = __builtin_malloc(1024);
*g = p;
return 0;
}
Without -DCALL_UNKNOWN:
./xgcc -B. -S t.c -fanalyzer
(no output)
With -DCALL_UNKNOWN:
./xgcc -B. -S t.c -fanalyzer -DCALL_UNKNOWN
t.c: In function ‘test’:
t.c:13:10: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
13 | return 0;
| ^
‘test’: events 1-2
|
| 11 | p = __builtin_malloc(1024);
| | ^~~~~~~~~~~~~~~~~~~~~~
| | |
| | (1) allocated here
| 12 | *g = p;
| 13 | return 0;
| | ~
| | |
| | (2) ‘p’ leaks here; was allocated at (1)
|
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495
2021-01-06 19:54 [Bug testsuite/98575] New: [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495 seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2021-02-04 23:02 ` dmalcolm at gcc dot gnu.org
@ 2021-02-04 23:16 ` dmalcolm at gcc dot gnu.org
2021-02-04 23:48 ` dmalcolm at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-04 23:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
The pertinent glibc commit was:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=26c07172cde74617ca7214c93cdcfa75321e6b2b
("Remove getc and putc macros from the public stdio.h.", 2018-02-06).
It's listed in the NEWS as in "Version 2.28", so presumably the test failure
occurs with glibc < 2.28.
That said, it's merely a symptom of the bug identified in comment #2
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495
2021-01-06 19:54 [Bug testsuite/98575] New: [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495 seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2021-02-04 23:16 ` dmalcolm at gcc dot gnu.org
@ 2021-02-04 23:48 ` dmalcolm at gcc dot gnu.org
2021-02-09 20:53 ` [Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-04 23:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
The false leak bug appears to very similar to PR analyzer/97072.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call
2021-01-06 19:54 [Bug testsuite/98575] New: [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495 seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2021-02-04 23:48 ` dmalcolm at gcc dot gnu.org
@ 2021-02-09 20:53 ` cvs-commit at gcc dot gnu.org
2021-02-09 20:55 ` cvs-commit at gcc dot gnu.org
2021-02-09 21:05 ` dmalcolm at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-02-09 20:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
--- Comment #5 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:1d9f3b7ad4f965a0acc21d42cb2d186ecd065b71
commit r11-7155-g1d9f3b7ad4f965a0acc21d42cb2d186ecd065b71
Author: David Malcolm <dmalcolm@redhat.com>
Date: Tue Feb 9 15:53:01 2021 -0500
analyzer: treat pointers written to *UNKNOWN as escaping [PR98575]
PR analyzer/98575 describes an unexpected -Wanalyzer-malloc-leak false
positive from gcc.dg/analyzer/pr94851-1.c on glibc < 2.28.
The issue is that a getchar call gets inlined into a call to _IO_getc,
and "_IO_getc" is not in the set of FILE * functions the analyzer
"knows about". This leads to a global pointer
struct buf *curbp;
being treated as UNKNOWN after the call to _IO_getc. Later when a
malloced pointer is written to curbp->b_amark, the write is discarded
(since curbp is unknown) without noting that the pointer has escaped,
and so the pointer is erroneously treated as leaking when the function
returns.
This patch updates the handling of *UNKNOWN to treat pointers written
to them as having escaped, fixing the false positive.
The patch stops the leak warning in gcc.dg/analyzer/explode-1.c.
After merging states at the join-point after the first switch, pp has
UNKNOWN value, and so *pp is a write through UNKNOWN, which with this
patch is now treated as escaping - despite the fact that all possible
values for *pp are on the stack. There doesn't seem to be a good way
to fix this, and the testcase is an artifically constructed one, so the
patch simply removes the dg-warning directive.
gcc/analyzer/ChangeLog:
PR analyzer/98575
* store.cc (store::set_value): Treat a pointer written to *UNKNOWN
as having escaped.
gcc/testsuite/ChangeLog:
PR analyzer/98575
* gcc.dg/analyzer/explode-1.c: Remove expected leak warning.
* gcc.dg/analyzer/pr94851-2.c: New test.
* gcc.dg/analyzer/pr98575-1.c: New test.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call
2021-01-06 19:54 [Bug testsuite/98575] New: [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495 seurer at gcc dot gnu.org
` (5 preceding siblings ...)
2021-02-09 20:53 ` [Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call cvs-commit at gcc dot gnu.org
@ 2021-02-09 20:55 ` cvs-commit at gcc dot gnu.org
2021-02-09 21:05 ` dmalcolm at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-02-09 20:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
--- Comment #6 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:790a8e8942b3f5a896ab5897cd209de1d9c382ae
commit r11-7156-g790a8e8942b3f5a896ab5897cd209de1d9c382ae
Author: David Malcolm <dmalcolm@redhat.com>
Date: Tue Feb 9 15:54:14 2021 -0500
analyzer: support "_IO_"-prefixed variants of FILE * fns [PR98575]
PR analyzer/98575 describes an unexpected -Wanalyzer-malloc-leak false
positive from gcc.dg/analyzer/pr94851-1.c on glibc < 2.28.
The issue is that a getchar call gets inlined into a call to _IO_getc,
and "_IO_getc" is not in the set of FILE * functions the analyzer
"knows about". This exposes a bug in memory leak detection on code
paths in which an unknown function has been called.
The memory leak bug is fixed in the prior commit, but for good
measure this patch special-cases the "_IO_"-prefixed names in glibc
so that the analyzer can reuse its knowledge about the unprefixed
variants.
gcc/analyzer/ChangeLog:
PR analyzer/98575
* sm-file.cc (is_file_using_fn_p): Support "_IO_"-prefixed
variants.
gcc/testsuite/ChangeLog:
PR analyzer/98575
* gcc.dg/analyzer/file-1.c (test_5): New.
* gcc.dg/analyzer/file-3.c: New test.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call
2021-01-06 19:54 [Bug testsuite/98575] New: [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495 seurer at gcc dot gnu.org
` (6 preceding siblings ...)
2021-02-09 20:55 ` cvs-commit at gcc dot gnu.org
@ 2021-02-09 21:05 ` dmalcolm at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2021-02-09 21:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #7 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Should be fixed by the above commits.
I verified the fix on gcc135.fsffrance.org in the GCC compile farm:
CentOS Linux release 7.8.2003 (AltArch)
powerpc64le-unknown-linux-gnu
glibc-2.17-307.el7.1.ppc64le
Please let me know if you're still seeing issues.
^ permalink raw reply [flat|nested] 9+ messages in thread