Bug 2075786 - possible bogus stringop-overread with memchr
Summary: possible bogus stringop-overread with memchr
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-04-15 10:19 UTC by Carlo Marcelo Arenas Belón
Modified: 2022-06-20 17:32 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Carlo Marcelo Arenas Belón 2022-04-15 10:19:29 UTC
Description of problem:
while building git with:

  make DEVELOPER=1

it will abort (it uses -Werror) while trying to build dir.c with the following message:

dir.c: In function ‘git_url_basename’:
dir.c:3085:13: error: ‘memchr’ specified bound [9223372036854775808, 0] exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread]
 3085 |         if (memchr(start, '/', end - start) == NULL
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

the issue is triggered with -O2 or higher in that codebase, but hadn't been able to generate a minimized reproducer.

Version-Release number of selected component (if applicable):
12.0.1-0.14.fc36

How reproducible:
100%

Steps to Reproduce:
1. get git sources (either from a release or git)
2. make DEVELOPER=1 dir.o
3.

Actual results:
build failure

Expected results:
no warnings

Additional info:
DEVELOPER=1 is used by git's CI which is likely to break with fc36 release, presume the fc36 package is showing the warning but has been ignored, hence fc36 will have a working git package

Comment 1 Carlo Marcelo Arenas Belón 2022-04-16 03:36:32 UTC
this has been reported in Debian as well, but couldn't find an upstreamed bug and don't have an account there (yet) to create one, if that would be preferred.

AFAIK, the issue might had even manifested itself with -O3 in a previous gcc version

Comment 2 Carlo Marcelo Arenas Belón 2022-05-24 20:35:01 UTC
based on additional investigation[1] from the Windows Git maintainer this might seem to be related to a known issue[2] in gcc which is labeled as WONTFIX.

[1] https://lore.kernel.org/git/365889ee96e37dc9dcbe60d98880eb256dae90ee.1653351786.git.gitgitgadget@gmail.com/
[2] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85783

Comment 3 Martin Sebor 2022-05-25 19:12:10 UTC
The two problems are unrelated.  The one here is due to GCC being overly conservative about the results of pointer subtraction, or more generally, not having the "smarts" to know that result of incrementing a pointer to an object is necessarily greater than or equal to the object's address.  For example, in the snippet below it's safe to assume that the condition is true (otherwise the program would be undefined), and eliminate the call to abort().  Because GCC doesn't do that, conditions like that hamper subsequent optimizations that in turn sometimes trigger false positive warnings.

void f (int n)
{
  char a[2], *p = a + n;
  if (p < a)
    abort ();
}

Comment 4 Aleksey Shipilev 2022-06-20 17:32:23 UTC
Possible sighting in OpenJDK: 
 https://bugs.openjdk.org/browse/JDK-8288759


Note You need to log in before you can comment on or make changes to this bug.