[sane-devel] [sane-pixma] Canon MF4150 v. PIXMA_CAP_LINEART
adam at certifound.com
Tue Aug 27 17:11:40 UTC 2013
On Wed, 21 Aug 2013 22:10:32 +0200, Rolf Bensch wrote:
> Hi Samuel,
> I prepared a quick patch to implement lineart for imageclass
Thanks! Preliminary testing update:
I applied your patch against git version af107912. It segfaults
without producing any noticeable activity in the scanner; and the
segfault occurs whether --mode is set to "Lineart", "Gray", or "Color".
I find this baffling, as on a brief glance the new lineart code path
*seems* to be largely branched over in other modes (at least in the
logical beginning thereof).
=> Question for those knowledgeable of the codebase: Could a segfault
in scanimage be likely caused by bad data from a rickety old scanner? I
only did a brief test thus far. If bad data could be the problem, I
will need to try repeatedly with reboots of the MF4150 unit. N.b.
however, stderr read exactly the same with SANE_PIXMA_DEBUG=4 and =21;
so the segfault appeared to occur before any USB traffic.
Compiling without the patch, git af107912 seeks to work (with some
flakiness). The first time I tried it, scanimage simply timed out
without any noticeable activity on the scanner; when I tried it again,
it worked. The hardware itself is in a condition akin to a car with
200k miles; so I need to retest more thoroughly, and verify whether said
weirdness was from the software or the scanner. The 1.0.23 (release)
code appeared to work just fine; but I did not use same beyond initial
checks, due to lack of lineart mode.
I will post further if i find anything interesting reading or testing
the code. Debugging pointers are welcome!
 I already know that even with a new Canon imageCLASS MF4150, either
the scanner itself or the Canon-provided Windows driver suffers what
smells to be a 32-bit integer overflow. When running sufficient scans
to total gigabytes of raw data (I am guessing either 2^31-1 or 2^32
even), the Windows driver hangs and requires a reboot of the computer.
Did I mention that I put 200k miles on (each of a few of) these
scanners? Same issue extant on x86 and x64.
If the scanner is periodically turned off and rebooted with its power
switch, the aforesaid limitation is avoided; thus I am unsure whether it
is some kind of byte counter in the scanner itself, or same in the
driver which resets when the hardware is re-initialized. While I don’t
recollect exactly what happened when I simply unplugged and replugged
the USB cable, I don’t think that sufficed as a workaround. Too bad I
can’t just peek at the source code...
More information about the sane-devel