Bug 574210

Is that possible to find a testcase?

I am trying to reproduce the problem. Since glibc has
processor-specific functions, please post

# cat /proc/cpuinfo

#:~$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz
stepping        : 6
cpu MHz         : 2267.000
cache size      : 3072 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority
bogomips        : 4522.09
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz
stepping        : 6
cpu MHz         : 800.000
cache size      : 3072 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority
bogomips        : 4521.75
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

It looks like that the problem does only happen on x86 systems. I could not reproduce this on x86_64.

The problem can also be reproduced on Fedora's build machines:
https://koji.fedoraproject.org/koji/taskinfo?taskID=2057255

I've observed also that the mono backtraces contains references to regular expression handling. Were there any regexp-related changes between the two glibc versions?

There are some regexp failures in glibc on Sparc:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385

They could be related. It may be a gcc bug.

(In reply to comment #4)
> There are some regexp failures in glibc on Sparc:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
> They could be related. It may be a gcc bug. 

The description in the gcc bug report indicates that the bug only happens in gcc 4.5: "gcc-4.4.x and gcc-4.3.x do not have this failure.". Since F-13 uses gcc 4.4.3 the gcc bug seems to be unrelated to the mono issue.

Gcc 4.4.3 in Fedora 13 contains some changes backported from trunk,
aka gcc 4.5.0, which aren't in FSF gcc 4.4.3.

Something seems wrong with regexp on Fedora 13. When I build glibc,
I got

/usr/local/bin/ld: /export/build/gnu/glibc/build-i686-linux/nptl/tst-_res1.o: undefined reference to symbol '_res'
/usr/local/bin/ld: note: '_res' is defined in DSO /export/build/gnu/glibc/build-i686-linux/nptl/tst-_res1mod1.so so try adding it to the linker command line
/export/build/gnu/glibc/build-i686-linux/nptl/tst-_res1mod1.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

(In reply to comment #7)
> Something seems wrong with regexp on Fedora 13. When I build glibc,

I've started the same test some hours ago, too. ;-)

On my F13 (fully updated) I could successfully rebuild glibc (make local in glibc/F-13).

I have also re-tested the failed glibc test cases from the mentioned gcc bug report: bug-regex20 and bug-regex11 work fine in F13 even with the new glibc.

Glibc 2.11.90-12 is OK. 2.11.90-13 and above are bad.

It is a memcmp bug. I have a patch.

Created attachment 401004 [details]
A patch for memcmp-sse3.S

This patch updates %xmm3 when exit from loop.

glibc-2.11.90-16 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/glibc-2.11.90-16

After upgrading to glibc-2.11.90-16, monodoc works for me.

(In reply to comment #13)
> After upgrading to glibc-2.11.90-16, monodoc works for me.    

I've just tested the new glibc in F13 - the problem seems to be fully solved! 

- I've tested a bunch of mono applications which do all work now again without any problems.
- Compiling mono itself works again, too.
- No other regressions found so far in the new build: rebooting the system, desktop environment etc. work without any issues.

H.J., thank you very much for the quick investigation and the bug fix!

glibc-2.11.90-16 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update glibc'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/glibc-2.11.90-16

glibc-2.11.90-16 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.