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: