Red Hat Bugzilla – Bug 114120
scanimage dies with Illegal instruction (including "fix")
Last modified: 2007-11-30 17:10:35 EST
Description of problem:
scanimage dies with Illegal instruction.
Version-Release number of selected component (if applicable):
Every invocation. Even happens with "scanimage --help"!
Steps to Reproduce:
1. Run scanimage
A scanned image would be nice. :)
For what it's worth, the hardware is (from lsusb):
Bus 001 Device 022: ID 04b8:010b Seiko Epson Corp. Perfection 1240
I installed the debuginfo rpm and debugged this very briefly. It dies
at sanei_debug_sanei_config_call+3. Here's a disassembly of the first
part of sanei_debug_sanei_config_call:
0x191610 <sanei_debug_sanei_config_call>: mov $0x15,%al
jmp 0x191613 <sanei_debug_sanei_config_call+3>
js 0x1915c0 <sanei_debug_msg+224>
0x191616 <sanei_debug_sanei_config_call+6>: add %eax,(%eax)
0x191618 <sanei_debug_sanei_config_call+8>: enter $0xeb15,$0xff
0x19161c <sanei_debug_sanei_config_call+12>: xchg %eax,%esp
0x19161d <sanei_debug_sanei_config_call+13>: stos %al,%es:(%edi)
0x19161e <sanei_debug_sanei_config_call+14>: add %eax,(%eax)
0x191620 <sanei_debug_sanei_config_call+16>: or %dl,(%esi)
jmp 0x191623 <sanei_debug_sanei_config_call+19>
What's interesting here is the branch from +2 to +3. +3 is not a
valid instruction; it's the middle of an instruction. Hence the
SIGILL. I don't know why the instruction at +2 is trying to branch to
the very next byte. Maybe an ld problem with relocations, or
something to do with dynamic relocation.
Or maybe it's that sane-backends became incompatible with some Fedora
Core 1 update. Doesn't seem likely, since it doesn't really seem like
an interaction with other system libraries or anything, but you never
know if something blew the dynamic linker's mind. FYI: I'm completely
up-to-date as of this morning, with the exception of the kernel which
is a couple revs old (too much hassle to reboot).
Instead of trying to figure out what went wrong, I tried to just
blindly make it better. :) I rebuilt the binary rpm from the source
rpm and installed the resultant binary rpm. It worked great. So, I'm
a happy camper. But you folks may want to do pretty much the same
thing (no doubt with an incremented release number) for a Fedora Core
Can you reproduce the problem by re-installing the as-shipped package?
You are quite right. I uninstalled the rebuilt rpm's and re-installed
the original ones from the Fedora Core 1 iso images, and they work
now. Eerie. Based on this evidence, I can only guess that some
object from sane-backends was mangled, causing the problem, so a
reinstall (of either the original or rebuilt rpm's) was all that was
necessary to fix it.
I just don't know how it got mangled. I don't generally play around
with funky versions of sane. Now I wish I'd done an "rpm -V" before
doing the first re-install. But that info is long gone now.
Perhaps it got mangled by a fsck or something. Yes, that must be it.
fsck always makes a good scapegoat. :)
I'll close this out.