Bug 858274 - index doesn't work correctly on i686 (causing FTBFS for openldap)
index doesn't work correctly on i686 (causing FTBFS for openldap)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
i686 Unspecified
high Severity high
: ---
: ---
Assigned To: Jeff Law
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-18 10:09 EDT by Jaroslav Škarvada
Modified: 2016-11-24 10:42 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-21 17:25:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cpuinfo (failing) (1.55 KB, text/plain)
2012-09-20 07:04 EDT, Jan Vcelak
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 14602 None None None Never

  None (edit)
Description Jaroslav Škarvada 2012-09-18 10:09:56 EDT
Description of problem:
index doesn't work correctly on i686. It prevents openldap package from rebuilding. Actually it may be glibc bug (I hadn't time to investigate it more deep).

Version-Release number of selected component (if applicable):
m4-1.4.16-6.fc19.i686

How reproducible:
Always

Steps to Reproduce:
1. echo "index(\`, enable_static, ', \`, enable_shared, ')" | m4
  
Actual results:
28

Expected results:
-1

Additional info:
It doesn't work with glibc-2.16.90-11.fc19.i686, but it works correctly with  glibc-2.16-7.
Comment 1 Jan Vcelak 2012-09-19 03:43:58 EDT
Please, resolve this ASAP. I will make a workaround in OpenLDAP till then.
Comment 2 Vitezslav Crhonek 2012-09-19 10:07:34 EDT
In my opinion this is glibc bug.

See this reproducer:

#include <stdio.h>
#include <string.h>
   
int main(void)
{  
  const char *haystack = ", enable_static, ";
  const char *needle = ", enable_shared, ";
   
  char *result;
  int retval;
   
  result = strstr(haystack, needle);
  printf("'%s'\n", result);
  retval = result ? result - haystack : -1; 
   
  printf("%d\n", retval);                                                       
  return 0;
}

# ./reproducer
', enable_shared, '
18

With glibc-2.16.90-11.fc19.i686, needle is found in haystack.
Comment 3 Jeff Law 2012-09-19 22:25:18 EDT
This is working fine for me in a mock environment.

It may be the case this problem is dependent upon the particular implementation of strstr in use -- there are multiple ones that are selected at runtime based on the processor's capabilities.

Can you please attach the contents of /proc/cpuinfo on a system where this is failing so that I can examine the flags and determine which of the strstr implementations is being used.

Thanks,
Comment 4 Jan Vcelak 2012-09-20 07:04:44 EDT
Created attachment 614849 [details]
cpuinfo (failing)

Attaching requested /proc/cpuinfo from a machine, where the problem presents in i686 mock environment.
Comment 5 Jeff Law 2012-09-20 11:40:17 EDT
Thanks.  That processor will use a different implementation than the box I tested on, if I'm reading all the strstr bits correctly.

I believe I've got a laptop here with similar capabilities which I can use for testing...  Or I can just hack up the sources to force the path that processor would take for testing/debugging purposes.
Comment 6 Jeff Law 2012-09-20 17:04:49 EDT
Appears to be introduced fairly recently by Maxim when optimizing the C strstr.
Comment 7 Jeff Law 2012-09-21 17:25:15 EDT
This should be fixed in rawhide.
Comment 8 Jan Vcelak 2012-09-24 04:40:13 EDT
I can confirm, that the problem disappeared with gcc-4.7.2-1.fc19.i686

Thanks.
Comment 9 Jakub Jelinek 2012-09-24 04:41:42 EDT
(In reply to comment #8)
> I can confirm, that the problem disappeared with gcc-4.7.2-1.fc19.i686

Except that it doesn't have anything to do with gcc.  It disappeared with glibc update.
Comment 10 Jan Vcelak 2012-09-24 04:59:04 EDT
(In reply to comment #9)
> Except that it doesn't have anything to do with gcc.  It disappeared with
> glibc update.

Of course (need a coffee): glibc-2.16.90-14.fc19.i686

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