From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: The file /usr/include/c++/3.2/i386-redhat-linux/bits/atomicity.h contain invalid asm instructios sequence (lock + xadd) on a i386 computer. The same file was used for building the stdc++ librairies. All the binaries linked with this librairy get a segfault as soon as they start to run (coming from libstdc++'s _init()) Just compile foo.c : int main() { return 0;} with gcc and -lstdc++ ./foo and it reproduces the bug Some binaries concerned: - many from kde (not very useful on my i386) :-) - many (all ?) groff package binaries - lftp - every binary compiled in the future with stdc++ support Traces with gdb (gdb) handle SIGSEGV nopass Signal Stop Print Pass to program Description SIGSEGV Yes Yes No Segmentation fault (gdb) run Starting program: /usr/bin/groff Program received signal SIGILL, Illegal instruction. std::locale::_Impl::_M_install_facet(std::locale::id const*, std::locale::facet*) (this=0x400c28e0, __idp=0x400c3604, __fp=0x400c2990) at /usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-linux /i386-redhat-linux/libstdc++-v3/include/i386-redhat-linux/bits/atomicity.h:40 in /usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-linux/i386-r edhat-linux/libstdc++-v3/include/i386-redhat-linux/bits/atomicity.h Current language: auto; currently c++ (gdb) info registers eip eip 0x4005dec2 0x4005dec2 (gdb) disassemble Dump of assembler code for function ... ... 0x4005debd <_ZNSt6locale5_Impl16_M_install_facetEPKNS_2idEPNS_5facetE+45>: mov eax,0x1 0x4005dec2 <_ZNSt6locale5_Impl16_M_install_facetEPKNS_2idEPNS_5facetE+50>: lock xadd DWORD PTR [edx],eax 0x4005dec6 <_ZNSt6locale5_Impl16_M_install_facetEPKNS_2idEPNS_5facetE+54>: inc eax Looking for informations about this, I found that the bug had just been resolved by the gcc/libstdc++ team only a few days ago. This is the URL of the message which gives the solution. http://gcc.gnu.org/ml/libstdc++/2003-04/msg00539.html The fix is more than easy. It seems (upon the author words) that this fix for the 3.3 branch is applicable to the olders one. Could you just condider fixing this in a future multi-fixes release on the 3.2 if ever ? not just waiting for gcc 3.4 in RH 12 :-) Don't assume that nobody cares about this i386 bug, because I do. Version-Release number of selected component (if applicable): libstdc++-3.2-7 How reproducible: Always Steps to Reproduce: 1.groff (for example) 2. 3. Actual Results: segfault Expected Results: Nothing, as I forgot to provide arguments to the command :-) But no segfault neither Additional info:
There is a kernel patch that emulates these instructions on i386. I don't think it is wise to sacrifice speed on 99.99% of boxes for the 0.01% installations.