Bug 90250 - unsupported asm instructions sequence cause sigill (and then segfault) in several binaries
Summary: unsupported asm instructions sequence cause sigill (and then segfault) in sev...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libstdc++   
(Show other bugs)
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-05 23:01 UTC by Eric Thomas
Modified: 2007-04-18 16:53 UTC (History)
0 users

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

Attachments (Terms of Use)

Description Eric Thomas 2003-05-05 23:01:08 UTC
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


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++ 
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
	in /usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-linux/i386-r
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 
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 

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.

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):

How reproducible:

Steps to Reproduce:
1.groff (for example)

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 10:36:53 UTC
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.