https://bugzilla.novell.com/show_bug.cgi?id=648718 https://bugzilla.novell.com/show_bug.cgi?id=648718#c79 Michael Matz <matz@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matz@novell.com --- Comment #79 from Michael Matz <matz@novell.com> 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 <enter.8102>: 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.