Bug 60763 - fabs() not signal safe (compiler bug)
Summary: fabs() not signal safe (compiler bug)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-03-06 04:29 UTC by John Reiser
Modified: 2016-11-24 14:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-06 04:30:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2002:056 contract SHIPPED_LIVE GNU C Library bugfix update 2002-04-02 05:00:00 UTC

Description John Reiser 2002-03-06 04:29:58 UTC
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 09:12:39 UTC
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.