Bug 858274 - index doesn't work correctly on i686 (causing FTBFS for openldap)
Summary: index doesn't work correctly on i686 (causing FTBFS for openldap)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: i686
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Jeff Law
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-18 14:09 UTC by Jaroslav Škarvada
Modified: 2016-11-24 15:42 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-21 21:25:15 UTC
Type: Bug
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Sourceware 14602 0 None None None Never

Description Jaroslav Škarvada 2012-09-18 14:09:56 UTC
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 07:43:58 UTC
Please, resolve this ASAP. I will make a workaround in OpenLDAP till then.

Comment 2 Vitezslav Crhonek 2012-09-19 14:07:34 UTC
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-20 02:25:18 UTC
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 11:04:44 UTC
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 15:40:17 UTC
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 21:04:49 UTC
Appears to be introduced fairly recently by Maxim when optimizing the C strstr.

Comment 7 Jeff Law 2012-09-21 21:25:15 UTC
This should be fixed in rawhide.

Comment 8 Jan Vcelak 2012-09-24 08:40:13 UTC
I can confirm, that the problem disappeared with gcc-4.7.2-1.fc19.i686

Thanks.

Comment 9 Jakub Jelinek 2012-09-24 08:41:42 UTC
(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 08:59:04 UTC
(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.