[sane-devel] [sane-pixma] Canon MF4150 v. PIXMA_CAP_LINEART

[Samuel Adam]

On Wed, 21 Aug 2013 22:10:32 +0200, Rolf Bensch wrote:

> Hi Samuel,
>
> I prepared a quick patch to implement lineart for imageclass 
> scanners.

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.[1]  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!

Samuel Adam


[1] 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...