[sane-devel] Oops . . here's the logs (xsane-win32/saned + epson 1650 prob)

[Henning Meier-Geinitz]

Hi,

On Wed, Jun 09, 2004 at 09:18:11PM -0700, Keith Clayton wrote:
> Hate when I do that . . here's the xsane logs described in my previous
> email

Ok, let's look at the second log. The preview scan looks ok (but I
don't know the details of the plustek backend). The real scan also
starts fine and then we see this:

[plustek] sane_read - read 3750 bytes
[saned] do_scan: read 3750 bytes from scanner
[plustek] usb_ScanReadImage() done, result: 0
[plustek] usb_ReadData()
[plustek] usb_ScanReadImage(3760)
[plustek] usb_ScanReadImage() done, result: 0
[saned] do_scan: trying to write 3754 bytes to client
[saned] do_scan: wrote 3754 bytes to client
[saned] do_scan: trying to read 1521 bytes from scanner
[plustek] sane_read - read 1521 bytes
[saned] do_scan: read 1521 bytes from scanner

Now these 1521 bytes should be sent to the frontend...

[saned] do_scan: processing RPC request on fd 4
[saned] process_request: waiting for request
[saned] process_request: bad status 22

saned thinks something has been sent to it by the control (not data)
connection. But when trying to decode what was sent it gets an error
when reading the first word. 22 is "invalid argument". That means that
no data could be read. Maybe xsane has crashed on the clent side
meanwhile? 

Usually during the scan nothing is sent to the control file descriptor.

Anyway. As sane_cancel isn't called the reader_process in the plustek
backend isn't killed and the plustek backend gets confused.

So my impression is that the problem is with xsane (or the net
frontend on windows) and the scanner lockup is just a consequence.
But I don't know why xsane (or the net backend) crashes. So maybe
finding out the details here may help- E.g. gdb xsane on the client or
enabling debugging for xsane and the net backend and looking at the
last few lines before the crash.

Maybe the xsane and plustek maintainers can have a look at the
logfiles, too?

Bye,
  Henning