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