[Bug testsuite/98575] New: [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[Bug testsuite/98575] New: [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[seurer at gcc dot gnu.org]

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

            Bug ID: 98575
           Summary: [11 regression] gcc.dg/analyzer/pr94851-1.c fails
                    after r11-6495
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:df1eba3ceada6e8990c00ccfa6c5a2c9b1c13334, r11-6495

The revision claims the message went away but I am still seeing it.

make  -k check-gcc RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/pr94851-1.c"
FAIL: gcc.dg/analyzer/pr94851-1.c bogus leak (test for bogus messages, line 43)
# of expected passes            1
# of unexpected failures        1


spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c
-fdiagnostics-plain-output -fanalyzer -Wanalyzer-too-complex
-fanalyzer-call-summaries -O2 -S -o pr94851-1.s
In function 'pamark':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:43:13:
warning: leak of 'p' [CWE-401] [-Wanalyzer-malloc-leak]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:24:29:
note: (1) following 'false' branch (when 'p' is NULL)...
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:29:6:
note: (2) ...to here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:29:6:
note: (3) following 'false' branch (when 'p' is NULL)...
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:32:23:
note: (4) ...to here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:32:23:
note: (5) allocated here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:32:8:
note: (6) assuming 'p' is non-NULL
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:32:8:
note: (7) following 'false' branch (when 'p' is non-NULL)...
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:35:15:
note: (8) ...to here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:37:8:
note: (9) following 'true' branch...
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:38:22:
note: (10) ...to here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr94851-1.c:43:13:
note: (11) 'p' leaks here; was allocated at (5)
FAIL: gcc.dg/analyzer/pr94851-1.c bogus leak (test for bogus messages, line 43)
Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled44120.cc   
-fdiagnostics-plain-output  -S -o exceptions_enabled44120.s    (timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled44120.cc
-fdiagnostics-plain-output -S -o exceptions_enabled44120.s
PASS: gcc.dg/analyzer/pr94851-1.c (test for excess errors)
testcase
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/analyzer.exp
completed in 0 seconds

                === gcc Summary ===

# of expected passes            1
# of unexpected failures        1

[Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[rguenth at gcc dot gnu.org]

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

[Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[dmalcolm at gcc dot gnu.org]

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)

[Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[dmalcolm at gcc dot gnu.org]

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)
      |

[Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[dmalcolm at gcc dot gnu.org]

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

[Bug analyzer/98575] [11 regression] gcc.dg/analyzer/pr94851-1.c fails after r11-6495

[dmalcolm at gcc dot gnu.org]

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.

[Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call

[cvs-commit at gcc dot gnu.org]

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.

[Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call

[cvs-commit at gcc dot gnu.org]

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.

[Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call

[dmalcolm at gcc dot gnu.org]

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.