[sane-devel] sane-backends (eposn2) segfaults pretty much all the time

[Paul Newall]

On 07/10/13 15:12, Chris Bagwell wrote:
> On Thu, Oct 3, 2013 at 1:34 PM, Johannes Bauer <dfnsonfsduifb at gmx.de> wrote:
>> On 03.10.2013 13:12, m. allan noah wrote:
>>> I would recommend that you use git bisect (or a manual equivalent) to
>>> find the commit that breaks epson2. Then we can investigate a fix.
>> This is really messed up:
>>
>> 206e6ed094c080be903b154ea3d016cc226feb89 is the first bad commit
>> commit 206e6ed094c080be903b154ea3d016cc226feb89
>> Author: m. allan noah <kitno-guest at alioth.debian.org>
>> Date:   Sat Jun 30 21:28:14 2012 -0400
>>
>>      Adding new kodakaio backend
>>
>>
>> The commit 206e6e is REALLY the first bad one (the one where it starts
>> segfaulting). Curiously there are no changes in epson2 in there.
>>
>> I confirmed that the predecessor,
>> df6a8ef89dbd061fb383722ddd6272e07fc468b3, is working (somewhat). At
>> least it is NOT segfaulting, but displaying in the end:
>>
>> [...]
>> Type ``scanimage --help -d DEVICE'' to get list of all options for DEVICE.
>>
>> List of available devices:
>> libusb: 0.000000 error [do_close] Device handle closed while transfer
>> was still being processed, but the device is still connected as far as
>> we know
>> libusb: 0.000043 error [do_close] A cancellation hasn't even been
>> scheduled on the transfer for which the device is closing
>>
>> (then it hangs indefinitely, as described before)
>>
>> No idea what the hell is going on here.
>>
>> Best regards,
>> Johannes
>>
> That info isn't to help on its own.  If its really calling
> scanimage.c:2040 thats a simple function thats unlikely to fail.  I
> suspect one of scanner drivers is corrupting memory while
> auto-detecting scanners and epson2 is the victim... and if removing
> the kodakaio driver improves things then maybe its that driver.
>
> Can you try editing your /etc/sane.d/dll.conf and commenting out all
> backends except epson2 and see if things work different?  If the
> bisect is pointing towards kodakaio driver then you can also try only
> commenting out that driver to try to narrow down to it.
>
> Chris
>
If commenting out kodakaio in /etc/sane.d/dll.conf solves the problem, 
then it might be possible to get extra diagnostic information by 
reenabling kodakaio in dll.conf and editing kodakaio.conf to stop it 
from doing usb auto-discovery and then stop it doing network auto-discovery.