Bug 90250 - unsupported asm instructions sequence cause sigill (and then segfault) in several binaries
unsupported asm instructions sequence cause sigill (and then segfault) in sev...
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: libstdc++ (Show other bugs)
8.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-05 19:01 EDT by Eric Thomas
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-07 06:36:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Thomas 2003-05-05 19:01:08 EDT
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:
Comment 1 Jakub Jelinek 2004-10-07 06:36:53 EDT
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.

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