https://bugzilla.novell.com/show_bug.cgi?id=648718
https://bugzilla.novell.com/show_bug.cgi?id=648718#c79
Michael Matz changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |matz@novell.com
--- Comment #79 from Michael Matz 2011-02-23 17:33:55 UTC ---
Okay, I have a machine available that reproduces this one with amarok.
The FPE in ld-linux.so is because the register ($esi) is zero:
000090f0 :
90f0: 55 push %ebp
90f1: 31 d2 xor %edx,%edx
90f3: 57 push %edi
90f4: 56 push %esi
90f5: 83 ec 08 sub $0x8,%esp
90f8: 8b 74 24 18 mov 0x18(%esp),%esi
90fc: 89 04 24 mov %eax,(%esp)
90ff: 8b 44 24 1c mov 0x1c(%esp),%eax
9103: 89 4c 24 04 mov %ecx,0x4(%esp)
9107: 8d 6e fe lea -0x2(%esi),%ebp
910a: f7 f6 div %esi <<<<<< FPE
Looking at the source, this can't happen. It's the size parameter which
starts from 31, and then only increases to next prime numbers. Indeed,
if running under gdb or valgrind, the FPE doesn't happen, and the first call
to enter.8102 (coinciding with the point where the crash would normally happen)
has this parameter be set to 61, which indeed is the next prime number
_dl_higher_prime_number would return for 31.
So, something between calculating that next prime number and this routine
is going fishy. As I have traced the source of the invalid zero somewhat
in a core file (the zero is already in the argument stack slot, and on the
caller side in a register where debuginfo isn't sufficient to trace it back
further), I would speculate that something clobbers the stack. I can't yet
rule out that something clobbers registers, though.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.