Bug 114120 - scanimage dies with Illegal instruction (including "fix")
scanimage dies with Illegal instruction (including "fix")
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: sane-backends (Show other bugs)
1
i686 Linux
high Severity high
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-22 14:32 EST by Todd Allen
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-28 10:17:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Todd Allen 2004-01-22 14:32:28 EST
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.
Comment 1 Tim Waugh 2004-01-28 06:05:57 EST
Can you reproduce the problem by re-installing the as-shipped package?
(I can't.)
Comment 2 Todd Allen 2004-01-28 10:17:19 EST
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.

Note You need to log in before you can comment on or make changes to this bug.