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
