Bug 60763 - fabs() not signal safe (compiler bug)
fabs() not signal safe (compiler bug)
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-05 23:29 EST by John Reiser
Modified: 2016-11-24 09:49 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-05 23:30:03 EST
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 John Reiser 2002-03-05 23:29:58 EST
Description of Problem:
Because of a compiler bug, fabs() stores and loads from addresses
that are below the stack pointer.  If a signal happens at the wrong
time, then the return value from fabs() will be wrong because
delivering the signal writes over the memory.

Version-Release number of selected component (if applicable):
glibc-2.2.4-19.3 (libm)

How Reproducible:
Inspect with gdb.

Steps to Reproduce:
gdb libm-2.2.4.so
x/23i fabs

Actual Results:
0x9e00 <fabs>:  push   %ebp
0x9e01 <fabs+1>:        mov    %esp,%ebp
0x9e03 <fabs+3>:        push   %edi
0x9e04 <fabs+4>:        fldl   0x8(%ebp)
0x9e07 <fabs+7>:        push   %esi   ## frame size is 8 bytes
0x9e08 <fabs+8>:        fstpl  0xfffffff0(%ebp)   ## need 16 bytes in frame
0x9e0b <fabs+11>:       mov    0xfffffff0(%ebp),%esi
0x9e0e <fabs+14>:       mov    0xfffffff4(%ebp),%edi
0x9e11 <fabs+17>:       mov    %esi,%eax
0x9e13 <fabs+19>:       mov    %edi,%edx
0x9e15 <fabs+21>:       and    $0x7fffffff,%edx
0x9e1b <fabs+27>:       mov    %eax,0xfffffff0(%ebp)
0x9e1e <fabs+30>:       mov    %edx,0xfffffff4(%ebp)
0x9e21 <fabs+33>:       fldl   0xfffffff0(%ebp)
0x9e24 <fabs+36>:       pop    %esi
0x9e25 <fabs+37>:       pop    %edi
0x9e26 <fabs+38>:       pop    %ebp
0x9e27 <fabs+39>:       ret
0x9e28 <fabs+40>:       nop
0x9e29 <fabs+41>:       lea    0x0(%esi,1),%esi


Expected Results:
0x9e00 <fabs>:	fldl 4(%esp)   # 0xdd 0x44 0x24 0x04
0x9e04 <fabs+4>:	fabs   # 0xd9 0xe1
0x9e06 <fabs+6>:	ret    # 0xc3


Additional Information:
The generated code is fat, slow and ugly, too.
Comment 1 Jakub Jelinek 2002-04-05 04:12:39 EST
This has been fixed in glibc-2.2.4-24 (and the fat, slow and ugly problem
is fixed in glibc-2.2.5-31; though it usually doesn't matter much since gcc
inlines fabs anyway, which is even faster).

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