Hide Forgot
Description of problem: scanimage dies with Illegal instruction. Version-Release number of selected component (if applicable): 1.0.12-4 How reproducible: Every invocation. Even happens with "scanimage --help"! Steps to Reproduce: 1. Run scanimage 2. 3. Actual results: Illegal instruction. Expected results: A scanned image would be nice. :) Additional info: 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 0x191612 <sanei_debug_sanei_config_call+2>: jmp 0x191613 <sanei_debug_sanei_config_call+3> 0x191614 <sanei_debug_sanei_config_call+4>: 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) 0x191622 <sanei_debug_sanei_config_call+18>: 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 1 update.
Can you reproduce the problem by re-installing the as-shipped package? (I can't.)
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.